Banca, tesorería y conectividad ISO 20022
Pagos de salida, extractos de entrada, conciliados automáticamente en todas las divisas
Los equipos de tesorería siguen reintroduciendo pagos y casando extractos a mano
Muchos equipos de tesorería introducen los pagos en portales bancarios, recogen extractos en formatos distintos de cada banco y concilian cuentas en hojas de cálculo a fin de mes. Cada paso manual es un retraso, un costo y una posibilidad de fraude o error.
Los bancos también están migrando a ISO 20022, el estándar internacional de mensajes financieros, que contiene datos estructurados más ricos que los antiguos formatos SWIFT MT. Los sistemas que no pueden generarlo ni leerlo se quedan atrás respecto a sus bancos.
Qué cambia para usted
Procesamiento directo
Las remesas de pago aprobadas salen del ERP como ficheros firmados o llamadas a la API, y los extractos vuelven en un formato que el ERP concilia por sí solo.
Un cierre más rápido
Conciliación multidivisa que se ejecuta a diario, en lugar de cargas manuales de CSV y ajustes de fin de mes en hojas de cálculo.
Cada excepción con una persona
Los pagos rechazados y las líneas sin casar llegan a una cola de excepciones de mensajes fallidos con su motivo, nunca se pierden en un buzón.
Qué entregamos
Conectividad host-to-host y directa con bancos
Conexiones por SFTP, EBICS y SWIFT, y API de banca abierta y bancarias directas, elegidas según cada banco y cada país.
Generación de ficheros de pago
Ficheros de pago ISO 20022 pain.001 construidos a partir de sus remesas, validados frente a la variante de cada banco y firmados o cifrados como este exija.
Gestión de estados y rechazos
Informes de estado pain.002 leídos de vuelta, para que cada pago figure como aceptado, rechazado o pendiente, con el código de motivo del banco.
Ingesta de extractos
Extractos de cierre camt.053 y MT940 e informes intradía recogidos, comprobados en busca de huecos y duplicados, y cargados en el ERP.
Mensajería interbancaria para bancos y fintechs
Mensajes pacs para transferencias de crédito y su estado entre entidades financieras, conectados a los libros mayores del core bancario.
Conciliación multidivisa
Reglas de casación que liquidan automáticamente partidas abiertas entre divisas y cuentas, y envían el resto a una cola de excepciones.
Evidencias de prueba bancaria y manuales de operación
Los casos de prueba de cada banco ejecutados y registrados para sus auditores, y alertas por ficheros ausentes, transferencias fallidas y claves o certificados a punto de caducar.
Cómo trabajamos
Mapear bancos y flujos
Enumeramos sus bancos, cuentas, tipos de pago y pasos manuales actuales, y acordamos qué flujos van primero.
Especificar cada formato
Partimos de la guía de implementación de cada banco y escribimos el mapeo, incluidos firma, cifrado y nombres de fichero.
Construir los conectores
Construimos la exportación de pagos, la importación de estados y extractos y la casación, con pruebas automatizadas para cada formato.
Probar con cada banco
Ejecutamos los casos de prueba acordados en el entorno de pruebas del banco y corregimos todo lo que rechaza su validación.
Entrar en producción banco a banco
Cambiamos un banco a la vez, con el proceso actual disponible como respaldo hasta que el nuevo esté probado.
Monitorizar y dar soporte
Vigilamos transferencias, claves y caducidad de certificados, y planificamos los cambios de formato a medida que los bancos los anuncian.
Desplácese en horizontal para ver el dibujo completo.
Del ERP al banco: salen pagos, entran extractos
Los pagos aprobados salen del ERP como archivos ISO 20022 firmados por un canal host-to-host. Los informes de estado y los extractos vuelven por la misma vía y se concilian con las partidas abiertas. Los rechazos y las partidas no conciliadas llegan a su equipo con el motivo adjunto.
- Flujo principal
- Asíncrono
- Ruta de excepción
El flujo en 10 pasos
El flujo, paso a paso
- De ERP a Capa de integración: Lote de pagos aprobado, mediante REST/JSON · IDoc (flujo principal).
- De Capa de integración a Canal bancario seguro: Archivo de pagos firmado y cifrado, mediante ISO 20022 pain.001 · OpenPGP (flujo principal).
- De Canal bancario seguro a Banco: Entregado al banco, mediante SFTP H2H (flujo principal).
- De Banco a Canal bancario seguro: Informes de estado y extractos, mediante pain.002 · camt.053 · MT940 (asíncrono).
- De Canal bancario seguro a Capa de integración: Recibidos y validados, mediante SFTP H2H (asíncrono).
- De Capa de integración a Motor de conciliación: Líneas del extracto, mediante camt.053 (asíncrono).
- De Motor de conciliación a ERP: Asientos conciliados registrados, mediante REST/JSON (flujo principal).
- De Capa de integración a Equipo de tesorería y finanzas: Pagos rechazados, con el código de motivo, mediante pain.002 RJCT (ruta de excepción).
- De Motor de conciliación a Equipo de tesorería y finanzas: Partidas no conciliadas: un descuadre de conciliación (ruta de excepción).
- De Equipo de tesorería y finanzas a ERP: Corregidos y reenviados (ruta de excepción).
Desplácese en horizontal para ver el dibujo completo.
Banca abierta: datos y pagos con el consentimiento del cliente
El cliente otorga su consentimiento, el conector guarda los tokens y cada llamada al banco queda autorizada y registrada. Cuando el consentimiento caduca o se revoca, la aplicación vuelve a pedirlo al cliente en lugar de fallar en silencio.
- Flujo principal
- Asíncrono
- Ruta de excepción
El flujo en 7 pasos
El flujo, paso a paso
- De Cliente a Su aplicación o plataforma: Otorga el consentimiento (flujo principal).
- De Su aplicación o plataforma a Conector de banca abierta: Solicitudes de cuentas y pagos, mediante REST/JSON (flujo principal).
- De Conector de banca abierta a API bancarias o agregador: Llamadas a la API autorizadas, mediante OAuth 2.0 · FAPI · REST (flujo principal).
- De API bancarias o agregador a Conector de banca abierta: Saldos, movimientos y estado de pagos, mediante REST/JSON · webhook (asíncrono).
- De Conector de banca abierta a ERP o contabilidad: Movimientos normalizados, mediante REST/JSON (flujo principal).
- De API bancarias o agregador a Conector de banca abierta: Consentimiento caducado o revocado, mediante HTTP 401 · 403 (ruta de excepción).
- De Conector de banca abierta a Su aplicación o plataforma: Se pide renovar el consentimiento (ruta de excepción).
Estándares, formatos y canales
Construimos a partir de la guía de implementación de cada banco, no solo del estándar. Nombrar un producto no implica una alianza con su fabricante.
- Estándares y canales bancarios
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- Swift
- EBICS
- SFTP (H2H)
- OpenPGP
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
Prueba en producción
Para un banco de primer nivel del CCG y su conglomerado regional, conectamos SAP S/4HANA con los rieles bancarios regionales sobre ISO 20022. Los pagos se firman, las excepciones llegan a colas de mensajes fallidos y la conciliación entre sus cuentas bancarias es automática.
Cómo empezar
Los requisitos claros de bancos y formatos pasan directamente a una propuesta. Varios bancos, países o una interfaz heredada sin documentar suelen empezar con el Blueprint Studio o con la Vía C: diagnóstico de sistemas existentes.
Próximos pasos
Sesión previa de consultoría
Una sesión de consultoría previa gratuita de 30 minutos en línea: repasamos sus objetivos, sistemas y restricciones.
Revisión de preparación
En una revisión de preparación gratuita de 48 horas, un Arquitecto Principal comprueba su proyecto frente a la Definición de preparado de 6 puntos y recomienda la vía que encaja.
Elegir la vía
Los proyectos con el alcance definido reciben una propuesta vinculante en un plazo de 3 a 5 días hábiles. Los proyectos en fase de concepto empiezan en el estudio con Blueprint. Un sistema en producción que falla, no está documentado o necesita integración empieza con un diagnóstico de 1 a 2 semanas. El estudio con Blueprint y el diagnóstico tienen cada uno un importe fijo, indicado en la propuesta.
Entrega en cinco etapas
Movilización, sprints con demostraciones en vivo, integración y endurecimiento, aceptación y puesta en producción, y después servicios gestionados. Tras el lanzamiento llega un periodo de garantía y, después, soporte y mantenimiento opcionales.
Proyectos de resultado fijo y servicios gestionados sin interrupción
Entrega de alcance fijo por hitos con responsables de entrega asignados, y servicios gestionados de aplicaciones sin interrupción bajo gobernanza de SLA.
Especialistas integrados y aumento de personal estratégico
Ingenieros principales y especialistas en nearshore y en sus instalaciones, y arquitectos de soluciones, transformación, PQC e integración integrados en su equipo.
Preguntas y respuestas
¿Qué es ISO 20022 y por qué importa?
ISO 20022 es el estándar internacional de mensajes financieros. Sus mensajes XML contienen datos estructurados, como nombres completos, direcciones y detalles del pago, que los antiguos formatos SWIFT MT no pueden llevar. Los bancos y sistemas de pago han migrado a él, así que los ficheros de pago y extractos construidos sobre este estándar concilian mejor y superan con más frecuencia los controles de cumplimiento.
¿Con qué formatos y canales bancarios trabajan?
Usamos pain.001 para pagos, pain.002 para estados, camt.052, camt.053 y camt.054 para informes de cuenta, y mensajes pacs entre bancos. También leemos los extractos MT940 y MT942 que muchos bancos siguen enviando. El transporte es host-to-host por SFTP, EBICS, SWIFT o API bancarias. Cada banco tiene su propia variante de cada formato, así que construimos a partir de su guía de implementación.
¿A qué sistemas ERP pueden conectarse los bancos?
SAP S/4HANA, Oracle Fusion Cloud ERP y NetSuite, Microsoft Dynamics 365, Odoo y Sage, así como sistemas de tesorería y a medida. Cuando el ERP tiene su propio módulo de comunicación bancaria, lo configuramos y ampliamos en lugar de construir alrededor de él.
¿Cómo mantienen seguros los ficheros de pago?
Los ficheros de pago se firman y cifran como exige cada banco y viajan solo por el canal acordado. Las claves y certificados se guardan en su almacén de claves o módulo de seguridad de hardware, nunca en el código. Los ficheros se validan antes de enviarse y cada transferencia queda registrada, para que pueda rastrear quién aprobó y envió cada pago.
¿Qué ocurre cuando una línea de extracto no casa?
Pasa a una lista de revisión con los candidatos probables y el motivo por el que no casó, como un importe distinto o una referencia ausente. Su equipo la resuelve ahí, y las reglas pueden ajustarse para que el mismo caso case la próxima vez. Nada se contabiliza en el libro mayor sin una casación que usted haya aprobado.
¿Qué marca el ritmo de una integración bancaria?
Sobre todo el banco, no el código. Cada banco fija sus pasos de alta, ventanas de prueba y aprobaciones, y algunos necesitan contratos o intercambio de claves antes de empezar las pruebas. Tras el mapeo le damos un plan por banco y empezamos a probar con el banco que esté listo primero.
¿Qué ocurre cuando un banco cambia su formato?
Los bancos anuncian los cambios de formato con antelación, como hicieron muchos al pasar de SWIFT MT a ISO 20022. Seguimos esos avisos para los bancos a los que conectamos, evaluamos el impacto y programamos el cambio y sus pruebas con el banco antes de su plazo.
¿Listo para construir? Pida una propuesta.
Envíe sus requisitos o su RFP. Nuestros arquitectos los validan y devuelven una propuesta vinculante de alcance fijo.
Próximos pasos
Revisión de preparación
En una revisión de preparación gratuita de 48 horas, un Arquitecto Principal comprueba su proyecto frente a la Definición de preparado de 6 puntos y recomienda la vía que encaja.
Propuesta vinculante
Tras validación de arquitectura sin costo, recibe una propuesta vinculante de alcance fijo en un plazo de 3 a 5 días hábiles: hitos, arquitectura, estructura del equipo y SLA. Firmamos un acuerdo de confidencialidad (NDA) con usted a petición, antes de que comparta sus requisitos.
Movilización
Cuando firma, nuestros equipos de ingeniería inician el Sprint 0 en un plazo de 5 a 10 días hábiles desde la firma del contrato.
Entrega en cinco etapas
Movilización, sprints con demostraciones en vivo, integración y endurecimiento, aceptación y puesta en producción, y después servicios gestionados. Tras el lanzamiento llega un periodo de garantía y, después, soporte y mantenimiento opcionales.