Reunión del workstream transfronterizo
10 y 11 de marzo (Londres/remoto)
Próximos pasos para el PI:
• Propuesta sobre cómo el CNP consulta y aloja los servicios de oracle y los objetivos globales - Adrian, Michael
• Identificadores compuestos, formas en que esto se recoge en el sistema o se expresa en las api - abierto
• Qué información se recoge en el modelo de datos o en la lista de extensiones - Michael
• Seguimiento con SWIFT para debatir los requisitos - Matt
Elementos abiertos:
• Finalizar los requisitos del CNP
• Tiene que agregar la información y reunirla en una única solicitud, y tendrán que firmar por separado
• Finalizar que el FXP tiene que gestionar los tipos de cambio, las liquidaciones y qué expira cuándo
• Los CNP pueden ampliar esto y determinar reglas adicionales del esquema de pagos
• El FXP gestiona los errores de redondeo
• El FXP garantiza una tasa dada
• ¿Cómo se incorpora al esquema a quienes no son de Mojaloop?
• Cómo integramos Mojaloop y algún esquema de pagos de Mojaloop para ofrecer pagos PVT completos: grupo de trabajo con Michael, Adrian, Sybrin y otros según haga falta
• Cómo gestionamos las solicitudes por motivos regulatorios
• Investigar las correspondencias de identificadores (mapear las cuentas de pathfinder y las cuentas móviles a los ID únicos de los DFSP)
• Investigar la certificación (hash y PKKI)
Notas detalladas de la reunión: Día #1: - Respuesta a la cotización
○ Cómo codificamos el SLA en la respuesta
○ Pedir a un 2.º CNP que enrute
○ En la API, hay que empaquetar cómo llevarlo hasta allí
○ Como CMP en Mowali, si devuelvo una respuesta de cotización, el esquema de pagos tiene implicaciones
○ Seguir toda la ruta del pagador al beneficiario
○ Limitar la participación del CNP: tiene que ser el último salto
§ ¿Cómo definir los requisitos de un CNP?
- Formato de los mensajes
○ Sintaxis http
○ Se partió del esquema de pagos de Mojaloop
§ Avanzar hacia que el CNP gestione la conversión
○ Versión de SWIFT
○ Seguridad: TLS
○ Cabecera y contenido cifrados en JWS
- Sistema minorista
○ Fuera de red: enviar remesa a alguien, hub
- Modelo de datos
○ Estructura: formas en que agregamos información nueva, rutas distintas, etc.
○ Privacidad: visibilidad y seguridad, accesible solo a quienes pueden verlo
○ Contenido del modelo de datos
- La transferencia se hace a través del switch (movimiento de dinero)
○ En mowali se expresan los montos, pero la tasa es importante porque afecta a las liquidaciones
§ Flujo de datos: agregamos la tasa cuando devolvemos la cotización
§ Agregado en la lista de extensiones, ¿debería formar parte del estándar?
§ Monto de envío y de recepción (moneda distinta)
- Elemento de datos
○ Tarifa de cada participante
○ El DFSP pagador las suma
○ Elemento de tarifa de la transacción
- Propuesta
○ Account Lookup Service
§ Lista de FSP locales
○ Switch: hay que mantener el estado y las solicitudes de búsqueda
§ Al emisor debería parecerle una transferencia nacional
§ Recoger la información y devolverla -
○ CNP: haciendo supuestos para cumplir los requisitos
§ ¿Hace falta ver la ruta?
§ Recoger información distinta aguas abajo
§ Los FSP emisores necesitan saber quién es el receptor
○ El CNP tiene que agregar la información y reunirla en una única solicitud, y tendrán que firmar por separado
§ La condición y el fulfilment forman parte de una estructura de PKI
§ Si hay más de un CNP, hay que asegurar que el DFSP beneficiario tenga certeza sobre el DFSP pagador: conexiones
§ El CNP necesita saberlo todo, reporte regulatorio -
○ ¿Necesitamos duplicar la estructura en una transferencia entre redes?
§ Intentando impedir que se una un socio deshonesto
§ Confiar en que el CNP cumpla sus SLA
○ De Mojaloop a otro esquema de pagos: no tenemos control
§ Exigir que confirmen la recepción
§ Cómo lo puedo saber
§ Cómo puedo saber que la persona del final recibió el dinero
○ Autoridad de firma externa para confirmar que se recibió el dinero
§ Si su esquema de pagos quiere participar en lo transfronterizo, entonces todos los participantes tienen que estar firmados
§ Clave pública: para unirse a una red de Mojaloop hay que emitir claves públicas
§ Autoridad central de emisión de certificados
§ Hace falta una estructura de PKI implantada
○ ¿Cómo se incorpora al esquema a quienes no son de Mojaloop?
§ Cómo integramos Mojaloop y algún esquema de pagos de Mojaloop para ofrecer pagos PVT completos: grupo de trabajo con Michael, Adrian, Sybrin y otros según haga falta
§ Identificar a los participantes: FSP, DFSP, todos han firmado
§ Partes: usuarios finales (Bob/Alice)
§ Una única transacción (con varias transferencias)
§ Nadie compromete sus fondos hasta que todos estén satisfechos
§ Cómo ampliar el esquema de pagos de Mojaloop y el que no es de Mojaloop
○ Certificación
§ Hash y PKKI
§ Red oro y plata
§ Socio nuevo: en producción en la red
§ El esquema de pagos decide los requisitos de la red
§ Certificado autofirmado
○ Liquidez
§ El FXP hace la gestión de posiciones
§ Qué requisitos ponemos a un FXP
§ El dinero móvil tiene menos flexibilidad
§ Reglas que se dieron entre esquemas de pagos
○ El FXP tiene que gestionar las liquidaciones, qué expira cuándo, etc.
§ El FXP tiene que gestionar la escasa validez de la cotización
§ Permitir que el FXP rechace las solicitudes
○ Cómo gestionamos las solicitudes por motivos regulatorios
§ Hay un diccionario
□ ¿Es obligatorio compartir el KYC?
□ Se pueden pedir muchas cosas: depende del participante
□ Hay que acordar el esquema de pagos de referencia
Día #2:
- Datos del Switch
○ Números de cuenta
○ Lista negra, lista blanca (supervisión y bloqueo)
○ Mantenerlo simple
○ Hub
○ Servicio lateral para quienes puedan hacerlo
§ Captura de datos móviles
§ Side car
§ Proceso digital
§ Servicios de valor agregado para el hub (servicio gestionado)
- Switch: hay que mantener el estado y las solicitudes de búsqueda
- El CNP puede ser un DFSP corriente
○ Todos los DFSP admiten todos los casos de uso
○ Participantes plenos (puede que solo presten un servicio de CNP o de FXP)
- Definición y requisitos del FXP
○ FXP: exigir tasas y tarifas como parte del servicio de cotización, hace falta una tasa estándar del sector
§ Los CNP pueden ampliar esto y determinar reglas adicionales del esquema de pagos
○ El FXP gestiona los errores de redondeo
○ Garantizar una tasa dada
○ Gestionar la liquidación entre esquemas
○ Tipos de cambio
○ Debería permitir a quienes solo hacen FX
○ Casos límite de fallo
§ Detalles en los mensajes de error para encontrar los errores
○ El FXP necesita devolver la información correcta
§ Cómo funciona el paso de mensajes
§ Casos límite: compartir lo hecho hasta la fecha
§ Jo tiene una API funcionando, identificada
§ Cambió la cotización (interceptó la cotización) --
§ Lista de extensiones de KYC: se amplió la cotización para esto
§ Las tasas están en la lista de extensiones (son la lista)
§ ¿Dónde se aplica el FXP?
§ Qué hacemos con las tarifas aguas abajo
□ (el DFSP beneficiario ocupa el lugar de la agregación)
- Cómo gestionar la resolución de identificadores
○ 2 tipos de identificadores
§ Globales (se pasan al CNP), para obtener una respuesta
§ Locales: se espera que los aporte el usuario
○ En Mojaloop usamos los identificadores como proxy
○ Los números de comercio pueden ser específicos de un esquema de pagos
○ Varios identificadores para una única cuenta
○ ¿Cómo identificamos la cuenta de forma única?
○ Apoyarse en el CNP (restringir cada identificador en este esquema de pagos)
○ Qué tipo de estructuras hay implantadas
○ Identificación por pasaporte: marcadores de posición
○ Mapear las cuentas de pathfinder y las cuentas móviles a los ID únicos de los DFSP
§ Servicio: la cuenta principal es X
§ Cada país tiene un servicio que presta
§ Cada CNP entiende el esquema de direcciones
§ El global: hay que saber qué vías usar
○ Envía un get parties al switch
§ El ALS nunca oyó hablar de ellos
§ 2 vías
□ Vía global (path finder y conversión a BIC)
- CNP
○ No aloja nada
○ Enrutar por el CNP: preguntar a otros
○ Construir las rutas alternativas
- No existe un registro global
○ Beneficiario último
○ Comunicación establecida
○ El reto es si podremos hacer que 2 DFSP compartan comunicación directa, ¿y será mucho pedir?
- El Switch tiene esquemas de pagos
○ Un operador del Hub que siga las reglas del esquema de pagos puede permitir nombres de FSP según decidan esas reglas
○ La tecnología o la propia Admin API no restringen los nombres (más allá de las restricciones de longitud, tipo o caracteres, etc.)
○ BGP: Border Gateway Protocol
- Consultar a cada CNP y después idear optimizaciones, una matriz que dé la ruta global; el objetivo sería no consultar al CNP directamente
• ¿Cómo conectarse con Mojaloop?
- Cualquier servicio financiero puede conectarse a Mowali
- Reglas del esquema de pagos, técnicas
- Regulatorias
- ¿Cómo asigno las cosas? Nadie conoce los pasos
- API de Mojaloop: entender esto.
- 2 instancias de Mojaloop: TIPs y Mowali
○ WOCCU, Asia, EE. UU.: solicitaron una instancia
○ Siguen ampliando los límites
- Cómo es una integración
○ Hacen falta sandbox, simuladores
○ Enfoque estándar
• Servicio de pagos por instancia
- Conseguir que los flujos fluyan de forma puntual
- Hacen falta libros mayores en tiempo real; ¿qué pasa si están fuera de línea?
- Excepción para fuera de red (los bancos aprovechan el flotante)
• Proceso de descubrimiento (FSP emisor)
- El Switch determina si tienen que contactar con un FXP
- En qué moneda puede recibir la cuenta receptora
- Varias búsquedas
- Modelo de datos: conjunto de cuentas, con una moneda en un DFSP
Asistentes:
- Mike, Patricia - Thume
- Michael R, Rob R, Sam - Modusbox
- Kim, Lewis - Crosslake
- Rolland, Greg, Phillip - Sybrin
- Vanburn -- Terrapay
- Megan, Simeon - Virtual
