Open Banking y APIs reguladas.
APIs reguladas que cumplen, sin sacrificar developer experience.
Open Banking obliga a los bancos a exponer datos y servicios a TPPs autorizados, con autenticación FAPI, mTLS, consentimiento explícito y trazabilidad completa. Con MuleSoft + Flex Gateway implementás el stack completo: gateway de seguridad, gestión de consentimientos como Process API, audit log inmutable y monitoreo regulatorio. Cumplimos PSD2, Open Banking Brasil, México y Colombia.
¿Qué resuelve Open Banking con MuleSoft?
El banco está obligado a exponer cuentas, transacciones y pagos a TPPs autorizados, en un formato estandarizado, con autenticación fuerte, consentimiento explícito y trazabilidad completa. Hacerlo bien protege la operación, abre canales de partnership con fintechs y deja al banco preparado para monetizar APIs premium en el mismo stack.
- FAPI (Financial-grade API) con mTLS, DPoP y signed JWT.
- Gestión de consentimientos como Process API auditable.
- Audit log inmutable cifrado para retención regulatoria.
- Rate limiting y políticas independientes por TPP autorizado.
Sistemas típicos involucrados
Las familias de sistemas que conviven en una implementación Open Banking enterprise.
Core bancario
Temenos T24, Veritran, Fiserv, NCR, IBS o cores Cobol/RPG custom como autoridad de cuentas, productos y movimientos.
Gestor de identidad
ForgeRock, Auth0, Okta o IdentityIQ para autenticación fuerte del cliente y gestión de access tokens.
Gateway de seguridad
Flex Gateway combinado con WAF y DDoS protection en el edge para terminar mTLS, validar DPoP y aplicar rate limiting por TPP.
Sistemas regulatorios
Audit log inmutable, gestor de TPPs autorizados, bitácora de consentimientos y reportes hacia el regulador local.
Arquitectura objetivo
API-Led con Flex Gateway en el edge, Experience APIs alineadas al spec y un consent service como pieza central.
+--------------+ +-------------+ +-------------+
| TPP fintech | | TPP fintech | | TPP fintech |
| A | | B | | C |
+------+-------+ +------+------+ +------+------+
| | |
+----+-----------+----+-----------+
| mTLS / FAPI / OAuth2
v
+----------------------------------------------+
| Open Banking Edge Gateway (Flex Gateway) |
| - mTLS + DPoP + signed JWT |
| - Rate limiting per TPP |
| - Threat protection |
+--------------------+-------------------------+
|
v
+----------------------------------------------+
| Experience APIs (Open Banking spec) |
| - /accounts /transactions /payments |
| - Sigue spec OFB Brasil / OB UK / etc. |
+--------------------+-------------------------+
|
v
+----------------------------------------------+
| Process APIs |
| - consent-pa: valida consent en cada call |
| - account-aggregation-pa |
| - payment-initiation-pa |
+--------------------+-------------------------+
|
v
+----------------------------------------------+
| System APIs (core-account, core-payment, |
| core-customer, audit-sapi) |
+--------------------+-------------------------+
|
v
+----------------------------------------------+
| Core bancario |
+----------------------------------------------+System APIs
core-account-sapi, core-payment-sapi, consent-sapi y audit-sapi exponen los movimientos del core bancario y la gestión de consentimientos como contratos canónicos auditables.
Process APIs
consent-pa valida el consentimiento ante cada request a APIs reguladas. account-aggregation-pa atiende a TPPs que piden múltiples cuentas. payment-initiation-pa orquesta el flujo PISP con SCA y antifraude.
Experience APIs
Las APIs visibles a TPPs siguen el spec regulatorio del país (OFB Brasil, PSD2, México Ley Fintech, Colombia). Headers FAPI, signing de respuesta y formato estricto, todo entregado por la capa Experience.
Flujo paso a paso
Cómo se atiende una consulta de saldo desde un TPP autorizado, end-to-end.
- 1 El cliente del banco autoriza al TPP a ver sus cuentas con un consent flow OAuth2 con redirect al banco. El banco emite un consentId con scope, validez y cuentas habilitadas.
- 2 El TPP recibe un access_token con scope accounts:read y el consentId asociado.
- 3 El TPP llama GET /open-banking/accounts/v1/accounts/{accountId}/balances con access_token, certificado mTLS y headers FAPI obligatorios.
- 4 Flex Gateway termina mTLS, valida que el certificado pertenece a un TPP autorizado, valida el DPoP y la firma del request JWT.
- 5 El gateway aplica rate limiting específico del TPP y políticas de threat protection antes de pasar al Experience API.
- 6 La Experience API llama a consent-pa para validar que el access_token corresponde al cliente, al TPP, al scope solicitado y que el consentimiento sigue activo y no expirado.
- 7 Si el consentimiento es válido, la Experience API llama a core-account-sapi GET /accounts/{id}/balance.
- 8 core-account-sapi consulta el core bancario y devuelve el saldo en formato canónico.
- 9 La Experience API formatea la respuesta según el spec regulatorio del país (campos exactos, decimales, currency code ISO) y agrega los headers de respuesta esperados.
- 10 El audit pipeline asincrónico registra la transacción completa en audit-sapi (request, response, timing, TPP, customer, scope) cifrada para retención regulatoria.
- 11 La respuesta vuelve al TPP en menos de 500 ms P95 según exigen los specs de Open Banking.
Patterns aplicados
Los patrones que sostienen una operación regulada en producción.
Mutual TLS
mTLS obligatorio entre TPP y banco. El gateway valida que el certificado del cliente está vigente y pertenece al TPP autorizado.
Token introspection
Cada request introspecciona el token con el authorization server. No se confía solo en el JWT firmado.
Idempotency keys
En payment initiation, la idempotency key garantiza que un reintento del TPP no ejecute el mismo pago dos veces.
Audit log inmutable
Write-only, cifrado, con retención de varios años exigida por la regulación. Pipeline asincrónico para no impactar la latencia.
Rate limiting por TPP
Cada TPP tiene su propio acuerdo de uso. Las políticas se aplican individualmente y se ajustan sin redeploy.
Circuit breaker al core
Protege al core bancario de cascadas de fallo. Cuando el core no responde, devuelve 503 con Retry-After estándar.
Cómo lo implementamos
Cinco fases del assessment regulatorio al CoE de Open Banking operando con autonomía.
Mapeo regulatorio y de TPPs
Lectura del spec aplicable (PSD2, OFB Brasil, México Ley Fintech, Colombia SuperFinanciera), inventario de productos a exponer, identificación de TPPs piloto y de los gaps en core, identidad y consent. Entregables: assessment regulatorio, gap analysis, plan de certificación.
Contratos API regulados y FAPI
Diseño de Experience APIs alineadas al spec, Process API de consent, System APIs sobre core, política FAPI en Flex Gateway, modelo de audit, política de retención. Plan de gobernanza de TPPs autorizados.
Implementación end-to-end
Construcción de las APIs, configuración de Flex Gateway con FAPI y mTLS, gestor de consentimientos, audit pipeline, scripts de provisioning de TPPs. Tests MUnit, pruebas de penetración tempranas, CI/CD a sandbox certificada.
Certificación y go-live
Hardening, security review, conformance testing del regulador, onboarding del primer batch de TPPs, ventana de monitoreo intensivo. Hypercare con el equipo del cliente y compliance.
Premium APIs y CoE
Activación de APIs premium monetizables sobre el mismo stack, expansión a nuevos productos, capacitación del equipo del cliente para gobernar TPPs y evolucionar el catálogo regulatorio con autonomía.
Requisitos del proyecto
Lo que tiene que estar disponible del lado del cliente para arrancar.
Datos mínimos
Catálogo de productos a exponer, política interna de consentimiento alineada con el regulador y datos de cuenta razonablemente limpios en el core bancario.
Licencias y capacidades
Anypoint Platform, Flex Gateway, conector al core bancario que aplique (Temenos, Veritran, Fiserv) y un IdP enterprise (ForgeRock, Auth0, Okta o IdentityIQ) para SCA del cliente.
Integraciones típicas
Core bancario, IdP, gestor de consentimientos, audit y reportería regulatoria, gestor de TPPs autorizados sincronizado con el directorio del regulador.
Pre-requisitos organizacionales
Sponsor de banca digital, área de compliance involucrada desde el día 1, security officer, equipo de seguridad operativa con playbook de revocación de TPPs y plan de certificación regulatoria.
KPIs operativos
Las métricas que típicamente mejoran tras la implementación. Sin números de mercado: cada banco fija su baseline regulatorio.
| KPI | Qué mide | Por qué importa |
|---|---|---|
| Latencia P95 por endpoint regulado | Latencia de respuesta de cada Experience API expuesta a TPPs. | El regulador define un SLA explícito; salirse implica reportes y posibles sanciones. |
| Regulatory SLA compliance | Porcentaje de requests dentro del SLA exigido por el regulador. | Es la métrica que se entrega en los reportes mensuales o trimestrales al regulador. |
| Consent validation failures | Requests rechazados por consentimiento inválido, expirado o insuficiente. | Distingue intentos legítimos mal configurados de potenciales abusos por parte de un TPP. |
| mTLS y signing failures | Handshakes mTLS y validaciones de firma JWT fallidas. | Indicador temprano de un certificado vencido, un TPP comprometido o un ataque dirigido. |
| TPP request volume | Volumen de requests por TPP autorizado. | Permite ajustar acuerdos comerciales, dimensionar y detectar anomalías de uso por TPP. |
| Audit completeness | Porcentaje de requests con registro de auditoría completo y cifrado. | Sin audit completo no hay defensa frente al regulador en una inspección. |
Time-to-value: primer endpoint regulado certificado tras 16 a 22 semanas desde el kickoff, dependiendo de la ventana del regulador.
Cómo se mide: dashboard entregado por Solu sobre Anypoint Monitoring, complementado con Splunk o Datadog y los reportes regulatorios formales hacia el regulador local.
Preguntas frecuentes
El driver original es bancario, pero la regulación se está expandiendo a Open Finance: aseguradoras, gestores de inversión, fintechs de crédito. La arquitectura es la misma — APIs reguladas con FAPI, consentimiento explícito y audit — y se aplica a cualquier vertical que entre en el marco regulatorio del país.
El regulador suele fijar latencias máximas (P95 o P99) por endpoint. La arquitectura se diseña para cumplirlas: audit pipeline asincrónico para no impactar la respuesta principal, Flex Gateway separado en alta disponibilidad, autoscaling en Process APIs, circuit breakers que protegen al core y devuelven 503 controlado en lugar de timeouts largos.
Como Process API y dataset gestionado: el directorio del regulador es la fuente de verdad, sincronizado periódicamente, y el equipo de operaciones puede dar de alta o suspender TPPs sin redeploy. Cada TPP tiene su rate limit, sus scopes habilitados y su política de monitoreo individual.
Se ejecuta un playbook de revocación: el TPP se suspende en el directorio interno, sus certificados se revocan en el PKI hub, todos sus consentimientos activos se invalidan y se notifica a clientes afectados según el protocolo del regulador. La arquitectura está diseñada para que esa revocación se aplique en minutos, no horas.
Sí. Sobre la misma plataforma se exponen APIs premium fuera del scope regulatorio (datos enriquecidos, capacidades de pago avanzadas, analytics) con su propio modelo de monetización, pricing por TPP, sandbox para developers y portal público. La parte regulada y la parte premium comparten infraestructura pero corren con políticas distintas.
Solu trabaja con la sandbox del regulador desde la fase de Build, con conformance testing automatizado contra el spec oficial. La fase de Deploy incluye una ventana específica de pruebas de certificación, security review independiente y documentación entregable al regulador. El plan de hypercare contempla el primer ciclo de reportes regulatorios.
Tu Open Banking, listo para la auditoría regulatoria.
Hablemos del estado de tu core, tu IdP y tu plan de certificación. Diseñamos juntos el roadmap.