Parte 17: Finanzas abiertas, APIs y economía de datos
De qué trata esta parte
La Parte 14 introdujo la banca abierta como una tendencia. Esta parte la abre por dentro: qué es exactamente un consentimiento, cómo se autoriza a un tercero sin entregarle una contraseña, qué contrato hay detrás de una interfaz y quién responde cuando un pago iniciado por otro sale mal.
Es la primera parte de la Etapa 5 y fija el método que usarán las seis siguientes: cada afirmación del material se acompaña de un cálculo o de una prueba que se puede ejecutar, y las decisiones de diseño se comparan siempre con la alternativa que no usa la tecnología de la que se habla.
El eje es que las finanzas abiertas no son una API: son un régimen de consentimiento del cliente con soporte técnico. Toda la parte se organiza en torno a esa distinción.
Prerrequisitos
| Parte | Clase | Qué aporta |
|---|---|---|
| 3 | Seguridad y consumo financiero | Protección del cliente y fraude |
| 12 | Regulación, cumplimiento y auditoría | Perímetro y actividad regulada |
| 14 | 3 · Banca abierta y APIs | Concepto y modelos de implantación |
| 14 | 4 · Datos en un banco | Gobierno del dato |
| 14 | 8 · Fraude digital | Autenticación y responsabilidad |
Resultados de aprendizaje
- Distinguir banca abierta, finanzas abiertas y datos abiertos, y explicar qué cambia en cada caso para el cliente, el proveedor y el supervisor.
- Diseñar un ciclo de consentimiento completo: alcance, vigencia, renovación, revocación y evidencia.
- Implementar y auditar un flujo de autorización con OAuth 2.x y OpenID Connect con los refuerzos que exige el perfil financiero.
- Especificar una API financiera versionada, idempotente y observable, con su contrato OpenAPI y sus pruebas de conformidad.
- Evaluar los riesgos sistémicos del modelo: concentración de agregadores, proveedores tecnológicos críticos y reparto de responsabilidad.
Competencias
| Competencia | Nivel esperado |
|---|---|
| Diseño de API financiera | Especifica, versiona y prueba |
| Autorización y criptografía aplicada | Implementa y audita |
| Gobierno del consentimiento | Diseña el ciclo completo |
| Análisis regulatorio | Ubica la actividad en el perímetro |
| Modelado de amenazas | Construye y prioriza |
Cómo se encadenan las 14 clases
La secuencia va del derecho a la operación, y cada bloque responde lo que el anterior deja abierto.
Clases 1 a 4 — el consentimiento y quién manda sobre el dato. Se empieza por lo único que hace legítimo todo lo demás: el permiso del titular. La clase 1 distingue banca abierta de finanzas abiertas y de datos abiertos; la 2 mapea a los actores y descubre al proveedor tecnológico crítico, que no tiene relación con el cliente y sostiene a cuarenta entidades; la 3 y la 4 construyen el ciclo de vida del consentimiento y su revocación, que es donde casi todos los diseños fallan.
Clases 5 a 9 — cómo se autoriza y cómo se llama. Con el consentimiento resuelto, aparece la mecánica: OAuth y OpenID Connect, el perfil reforzado que exige el sector financiero, la firma de mensajes y el contrato de la interfaz. Aquí se aprende que una interfaz sin contrato versionado no es una integración: es una dependencia.
Clases 10 a 14 — el pago, la responsabilidad y la operación. La iniciación de pagos añade la parte irreversible, y con ella la idempotencia y el reparto de responsabilidad cuando algo sale mal. La parte cierra con la operación real: disponibilidad, presupuesto de error y el proyecto que integra todo.
Secuencia
- Banca abierta, finanzas abiertas y datos abiertos
- Ecosistema, participantes y modelos de implantación
- El Sistema de Finanzas Abiertas de Chile
- Clasificación, calidad y gobierno de datos financieros
- Consentimiento: creación, vigencia, renovación y revocación
- OAuth, OpenID Connect y autorización financiera
- Financial-grade APIs, certificados y firma de mensajes
- Diseño, versionado e idempotencia
- APIs de cuentas, productos, créditos, seguros e inversiones
- Iniciación de pagos y confirmación de fondos
- Autenticación reforzada, fraude y responsabilidad
- Privacidad, finalidad, minimización y portabilidad
- Disponibilidad, SLA, observabilidad e incidentes
- Proyecto: agregador financiero regulado
Laboratorios
| # | Laboratorio | Entregable principal |
|---|---|---|
| 1 | Consentimiento granular | Modelo de alcances y evidencia |
| 2 | Servidor de autorización simulado | Flujo con PKCE y validación de tokens |
| 3 | API de cuentas y movimientos | Contrato OpenAPI y paginación |
| 4 | Iniciación de pagos | Idempotencia y máquina de estados |
| 5 | Panel de consentimientos | Revocación con efecto verificable |
| 6 | Conformidad y seguridad | Batería de pruebas negativas |
Evaluaciones
Proyecto
Evidencias
- Mapa de alcances de consentimiento con su base de licitud.
- Flujo de autorización ejecutado y trazado extremo a extremo.
- Contrato OpenAPI validado.
- Registro de pruebas de conformidad, incluidas las negativas.
- Modelo de amenazas priorizado.
- Matriz de responsabilidad ante fraude.
Mapa de dependencias
Parte 14 (introducción fintech)
└── Parte 17 — finanzas abiertas
├── Parte 18 · iniciación de pagos en contexto transfronterizo
├── Parte 21 · identidad y elegibilidad en mercados tokenizados
├── Parte 22 · perímetro regulatorio del prestador
└── Parte 23 · capa de consentimiento del banco digital
Aplicación asociada
Fuentes oficiales de referencia
- Comisión para el Mercado Financiero (Chile) — normativa del Sistema de Finanzas Abiertas.
- Banco Central de Chile — normativa de sistemas de pago.
- OpenID Foundation — perfiles FAPI.
- IETF — RFC 6749, RFC 7636, RFC 8705, RFC 9449.
- Bank for International Settlements — informes sobre open banking y open finance.
Limitaciones
- La normativa chilena de finanzas abiertas está en despliegue por fases: cada clase indica la fecha de verificación y qué debe revisarse en la fuente oficial.
- Los perfiles de seguridad citados evolucionan; se indica la versión mencionada y se pide comprobar la vigente.
- El material no habilita a conectarse con entidades reales ni sustituye el proceso de inscripción o autorización ante el supervisor.