Técnico

FAPI

Financial-grade API — perfil de seguridad OAuth para las finanzas

Perfil de seguridad OAuth 2.0 / OpenID Connect diseñado específicamente para las API financieras. Estandarizado por la OpenID Foundation, FAPI 1.0 (final 2021) y FAPI 2.0 (final 2024) refuerzan la autenticación, el binding de token y la protección frente a ataques. Usado por OBIE UK, CDR Australia, Open Finance Brazil.

Definición

FAPI (Financial-grade API) es un perfil de seguridad de OAuth 2.0 y OpenID Connect diseñado para las API financieras.

Estandarizado por la OpenID Foundation, es el estándar de referencia mundial para la seguridad del Open Banking. Endurece OAuth/OIDC al imponer algoritmos fuertes (PS256, ES256), un binding estricto de los tokens (mTLS, DPoP), mecanismos anti-tampering (JAR, PAR), respuestas firmadas y una certificación rigurosa.

Coexisten dos versiones principales: FAPI 1.0 (final en marzo de 2021, con los perfiles Read-Only y Read-Write) y FAPI 2.0 Security Profile (final en febrero de 2025), que simplifica e integra de forma nativa PAR y DPoP/mTLS.

Por qué FAPI

OAuth 2.0 es demasiado laxo para las finanzas: implementaciones variables, ataques conocidos (CSRF, mix-up, code injection), tokens no vinculados. FAPI aprieta las tuercas:

  • token vinculado al cliente (mTLS o DPoP) — un token robado es inutilizable;
  • request firmado (JAR) — imposible modificar un consentimiento en tránsito;
  • PAR — el request_uri es corto y no filtrable en los logs;
  • algoritmos fuertes únicamente;
  • ID Token firmado — verificable del lado del cliente.

FAPI 1.0 vs FAPI 2.0

AspectoFAPI 1.0 (Advanced)FAPI 2.0 (Security Profile)
PerfilesBaseline (lectura) + Advanced (escritura)Uno solo
Token bindingmTLS u OAuth Token BindingmTLS o DPoP (a elegir)
RequestJARM requeridoPAR + JAR requeridos
AlgoritmosPS256, ES256PS256, ES256 (simplificado)
Hybrid flowRequerido (Advanced)Eliminado (PAR lo reemplaza)
AdopciónMasiva (2021-2024)En curso (2024-2027)

FAPI 2.0 es más sencillo de implementar correctamente, más seguro por defecto y más interoperable.

Componentes técnicos

  • mTLS: el cliente se autentica mediante un certificado X.509 (a menudo un QWAC en la UE); el token queda vinculado a ese certificado.
  • DPoP: alternativa a mTLS, basada en un JWT firmado por una clave privada, más sencilla para el móvil y las SPA (adoptada en FAPI 2.0).
  • PAR: el cliente envía su petición de autorización a través de una API back-channel y recibe un request_uri opaco — anti-tampering, anti-leak.
  • JAR: la petición OAuth se encapsula en un JWT firmado, imposible de modificar en tránsito.
  • JARM: respuesta OAuth firmada en un JWT, verificable del lado del cliente.

El flujo FAPI 2.0 típico

Adopción

  • Reino Unido (OBIE): FAPI 1.0 Advanced, con bancos y TPP todos conformes — el modelo de referencia mundial.
  • Brasil (Open Finance Brazil): FAPI 1.0 Advanced (luego 2.0), exigido por el BCB, más de 800 instituciones — el mayor ecosistema de Open Finance.
  • Australia (CDR): FAPI 1.0 Advanced, exigido por la ACCC y el Treasury.
  • En otros lugares: Berlin Group y STET se inspiran en él pero son menos estrictos (mTLS y JAR a menudo opcionales). La UE sigue siendo la zona más permisiva, de ahí los debates recurrentes sobre imponer FAPI en la DSP3.

FAPI vs Berlin Group / STET

AspectoFAPI 1.0 AdvancedBerlin Group XS2A
Perfil OAuthEstricto (mTLS + JAR + JARM)Más flexible (mTLS opcional)
Auth del clienteQWAC mTLS obligatorioQWAC a menudo (variable)
Firma de los mensajesBanco + cliente (QSealC)QSealC a menudo requerido
Token bindingVinculado por mTLSNo vinculado (bearer)
CertificaciónFAPI ConformanceSin certificación global

La DSP2/DSP3 es, por tanto, menos "FAPI" que el Reino Unido, Brasil y Australia, lo que complica la interoperabilidad internacional.

Conformance y certificación

La OpenID Foundation ofrece una suite de pruebas FAPI Conformance (para AS y clientes). En caso de éxito, la certificación se publica en su sitio, con la lista de los bancos y TPP conformes — un pasaporte de calidad para integrar los ecosistemas OBIE, CDR u OFB.

Lo que FAPI no es

  • No es un estándar de API de negocio: cubre la seguridad OAuth, no el formato de los endpoints /accounts o /payments (definido por OBIE, Berlin Group, STET, FDX).
  • No es obligatorio en la DSP2 / DSP3: recomendado, no impuesto por los RTS.
  • No está reservado al Open Banking: aplicable a cualquier API financiera.
  • No es un reemplazo de OAuth: es un perfil reforzado de OAuth 2.0 + OIDC.

En el ecosistema PSD2 / Open Finance

FAPI es el gold standard mundial de la seguridad del Open Banking: referencia fuera de la UE (Reino Unido, Brasil, Australia), menos estricto en la UE (Berlin Group, STET), con una convergencia hacia FAPI 2.0 esperada vía DSP3 y FIDA. Combinado con la EUDI Wallet, forma el combo identidad + API segura del Open Finance ampliado.

Ejemplos concretos

  • OBIE UK: implementación FAPI madura, con bancos y TPP certificados.
  • Plaid, TrueLayer, Tink: FAPI 1.0 Advanced (Tink certificada por la OpenID Foundation).
  • Bridge: STET + Berlin Group, sin FAPI estricto.
  • Banco do Brasil, Bradesco, Itaú: certificados FAPI en el OFB.
  • Herramientas: Authlete (JP), Curity (SE), ForgeRock (EE. UU.) admiten FAPI de forma nativa.
  • Migración FAPI 2.0: el OFB prevé una transición 2025-2027, el OBIE la estudia.
  • Coste: para un banco, el soporte de FAPI 2.0 representa un proyecto de 2 a 5 M€ (frente a ~200 mil € para un OAuth básico), justificado por la seguridad y la interoperabilidad internacional.

Fuentes

Profundizar

En el blog

Lecturas más completas para ir más allá de la definición.

7 de abril de 2026
técnico

Arquitectura técnica de una API DSP2: lo que hay que saber antes de escribir la primera línea de código — Leer el artículo

Panorama técnico de la DSP2 para CTO, desarrolladores y PM técnicos: estándares de API, seguridad (mTLS, certificados eIDAS), OAuth2, flujos SCA, gestión del consentimiento, trampas de implementación.

6 de abril de 2026
regulación

Entender la PSD2: lo que cambia para sus clientes y su negocio — Leer el artículo

Todo lo que un directivo, un product manager o un equipo de negocio debe entender de la PSD2 (DSP2). Actores, consentimiento, oportunidades, sin jerga técnica.