Introduction
Who the actors are, the FAPI 2.0 security model, and the shape of a data-recipient integration with Protección.
Introduction
Protección's Data Provider platform lets an accredited data recipient (you) access a customer's financial data — banking accounts and transactions, energy accounts and usage — with the customer's explicit, revocable consent.
This guide is written from the data recipient's point of view. It walks the full integration in order: set up mutual TLS, run a consent authorisation, manage the consents a customer has granted you, and request data with the token you receive.
The actors
There are three parties in every data-sharing flow.
| Actor | Who it is | Responsibility |
|---|---|---|
| Data recipient | Your application | Requests consent and consumes data. Authenticates to Protección with a client certificate. |
| Data provider | Protección (on Fiskil) | The authorization server and consent manager. Runs PAR, token issuance, consent screens, and token binding. |
| Resource server | The customer's data holder | Holds the underlying accounts and transactions. You never call it directly — Protección brokers every request. |
Data recipient ⇆ Protección (Data Provider) ⇆ Resource server
(you) authorization + consent (the data)A security profile, not just OAuth
Protección implements the FAPI 2.0 Security Profile — the OpenID Foundation's hardened profile for high-value financial data. It constrains ordinary OAuth 2.0 and OpenID Connect with a set of strict rules:
- PAR — authorization parameters are pushed server-to-server before the customer is redirected, so nothing sensitive appears in the browser URL.
- PKCE (S256) — every authorization code is bound to the client that started the flow.
- Sender-constrained tokens — access tokens are cryptographically bound to your client certificate (mTLS) or a DPoP key, so a stolen token is useless on its own.
private_key_jwt/tls_client_auth— you authenticate with keys, never a shared secret.- Issuer identification — responses carry an
issparameter so you can detect mix-up attacks.
Protección owns the entire security stack. You never implement PAR, token binding, or consent screens yourself — you drive the flow as a client and validate what you receive.
What you build vs. what Protección handles
You build
A confidential client that authenticates with mTLS, drives the authorization flow (PAR → authorize → token), stores consent identifiers, and calls the data endpoints with the right scopes.
Protección handles
The FAPI authorization server, consent screens and lifecycle, certificate binding, token issuance, brokering to the resource server, and regulatory reporting.
Environments
Each integration has isolated staging and production instances, each with its own discovery document, endpoints, and certificates. Build against staging, then swap the base host when you go live.
| Instance | Example issuer |
|---|---|
| Staging | https://public.proteccion.staging.provider.fiskil.com |
| Production | https://public.proteccion.prod.provider.fiskil.com |
Everything else — endpoints, JWKS, scopes — is discovered from the instance's /.well-known/openid-configuration, so you never hardcode URLs.