- Jaime González Gasque
- 55 minutes ago
- 3 min read
Lecciones aprendidas al poner en marcha eKash (Ruanda) e implementar SSIIPS (Sudán del Sur): dónde destaca la base de código abierto y dónde la escala nacional exige ingeniería a medida.
¿QUIÉNES SOMOS?
Empresa de ingeniería con sede en Kigali, dedicada al desarrollo de infraestructura de pagos y finanzas abiertas.
42 ingenieros, Kigali, Ruanda
2 programas de conmutación nacional
1 Mojaloop, 2 implementaciones
eKash - Conmutador nacional de Ruanda basado en Mojaloop (RNDPS 2.0), desarrollado para RSwitch Ltd. Entregado y en funcionamiento.
SSIIPS - Sudán del Sur: Sistema nacional de pagos instantáneos basado en Mojaloop para el Banco de Sudán del Sur. En implementación.
En la comunidad: Líder del grupo de trabajo de Banca Abierta; socio de canal certificado para Tazama, el sistema de código abierto de gestión de fraude y riesgos.
¿QUÉ FUNCIONA BIEN DESDE EL PRIMER MOMENTO?
Para el desarrollo en las primeras etapas y las pruebas en entornos de prueba, la base de código abierto elimina la mayor parte de las dificultades iniciales.
✓Base de despliegue de infraestructura.
Para entornos estándar, las configuraciones de gráficos de Kubernetes y Helm ofrecen una ruta de infraestructura como código simplificada para la implementación de los microservicios principales. Esto reduce significativamente las dificultades para poner en marcha el conmutador principal.
✓El kit de herramientas de prueba.
Invaluable para validar el cumplimiento básico de la API y confiable para simular el comportamiento de DFSP durante las fases de prueba inicial y sandbox. Nuestras pruebas de comodidad de implementación de conmutadores en ambos programas comenzaron con el kit de herramientas de prueba.
BRECHA 1: SE REQUIERE DESARROLLO A MEDIDA.
Mojaloop realiza la liquidación y el procesamiento. Un sistema nacional requiere un conjunto completo de funcionalidades empresariales. A continuación, se muestra lo que desarrollamos a medida en nuestros despliegues.
Conector ISO 20022 con XMLDSig:
Específico para cada país en el marco del RNDPS: transformación de mensajes más firmas digitales XML para garantizar la integridad y el no repudio.
Portales de administración del hub y del DFSP:
Interfaces operativas para el operador del hub y portales de autoservicio para los participantes: incorporación, configuración y visibilidad.
Conciliación automática integral.
Comparación automatizada a lo largo de toda la transacción, lo que permite verificar las posiciones de forma continua en lugar de investigarlas a posteriori.
Gestión de disputas.
Flujos de trabajo estructurados para excepciones, reembolsos y disputas sobre las reglas del plan entre los participantes: una obligación del plan, no un extra opcional.
Integración con el sistema RTGS:
La finalidad de la liquidación implica conectar el conmutador al sistema RTGS del banco central: sus formatos, sus ventanas y sus límites de tiempo.
Integración con Tazama FRMS:
Detección de fraude y riesgo en tiempo real integrada en el flujo de transacciones desde el primer día, mediante la plataforma de código abierto Tazama.
BRECHA 2: DESARROLLO PERSONALIZADO REQUERIDO.
Las herramientas estándar indican el estado de los pods. Un conmutador nacional debe saber si los pagos se realizan correctamente.
Lo que obtendrá:
Métricas básicas del estado de la infraestructura.
Estado de pods, nodos y niveles de servicio.
Paneles de control y alertas genéricas.
Lo que tuvimos que desarrollar:
Paneles de control centrados en el negocio para el seguimiento de los SLA financieros.
Vistas del éxito, la latencia y los fallos de las transacciones de cada DFSP.
Resumen del estado de liquidación y conciliación.
Alertas vinculadas a las obligaciones del plan, no a la CPU.
BRECHA 3: DESARROLLO PERSONALIZADO REQUERIDO.
Los gráficos Helm predeterminados no proporcionan un entorno de producción robusto y multirregión.
La topología multirregión se diseñó a medida.
La verdadera alta disponibilidad y recuperación ante desastres implican el diseño de clústeres activo-activo o activo-pasivo entre regiones.
Los servicios con estado son la parte más compleja.
Kafka y las bases de datos principales requieren una replicación entre regiones cuidadosamente diseñada. La consistencia, el comportamiento de conmutación por error y los objetivos de punto de recuperación son decisiones de diseño reales, no valores predeterminados.
NUESTRA PERSPECTIVA.
El código abierto elimina la dependencia de un proveedor, pero reemplaza la tarifa de licencia con un costo por funcionalidad.
Lo que se evita:
La dependencia de un proveedor, la economía de licencias por transacción y las hojas de ruta definidas por las prioridades comerciales de otros.
Lo que se asume:
La obligación de proteger, parchear y escalar el sistema de forma independiente, para siempre.
Esto exige una inversión masiva y constante en la capacidad del equipo:
Ingenieros locales de DevOps responsables de los clústeres, los flujos de trabajo, las actualizaciones y la respuesta a incidentes.
Especialistas en seguridad que monitorizan las vulnerabilidades (CVE), gestionan el ciclo de parches y refuerzan la infraestructura.
Ingenieros de software que amplían, integran y optimizan el rendimiento del switch.
Por Alain Kajangwe – Cofundador y CEO de WiredIn Ltd.
www.wiredin.rw | Kigali, Rwanda