Financial Services

Identity for financial services.
Built for FAPI & Open Banking.

FAPI 1.0 Advanced, PSD2 Strong Customer Authentication, mTLS-bound short-lived tokens, and KYC orchestration. The identity layer banks and fintechs can certify against.

Available on Enterprise and above. See pricing

Start free Read the docs

The security profile

FAPI 1.0 Advanced, enforced — not documented.

The Financial-grade API profile hardens plain OAuth 2.0 / OIDC into something a bank can certify against: it mandates how the client authenticates, which signature algorithms are legal, how request parameters are integrity-protected, and how tokens are bound to their holder. The gap most teams hit is that these are recommendations in their stack — a misconfiguration away from an insecure path. Activate the finance module and AuthFI enforces every constraint at the protocol layer: the insecure path is not reachable, so there is nothing to certify around.

Sender-constrained client auth

Token endpoint accepts private_key_jwt or mTLS only. Shared client secrets are rejected.

Asymmetric signing only

PS256 / ES256 enforced. RS256 and "none" are forbidden — at the algorithm level, not by convention.

Signed request objects

JAR (RFC 9101): authorization parameters must arrive in a signed request object. Tampering is detectable.

mTLS cert-bound tokens

Access tokens are bound to the client certificate (RFC 8705). A leaked token cannot be replayed by anyone else.

Detached signature integrity

s_hash in the id_token when state is present (FAPI §5.2.2.1); response_type code id_token, or plain code with JARM.

Data minimisation

AML risk scores and KYC status never enter access tokens. Only the claims the RP needs to decide (GDPR Art. 5(1)(c)).

Token posture

A stolen token expires before it's useful.

A bearer token is a password the moment it leaves the wire — anyone holding it can replay it until it expires, which on a standard tenant is hours. FAPI closes both halves of that risk. AuthFI caps finance-tenant access-token lifetime to minutes, regardless of any longer tenant default, and binds each token to the client's mTLS certificate per RFC 8705: the resource server confirms the presenter holds the matching private key, so an exfiltrated token replayed from anywhere else is rejected. Short life shrinks the window; sender-constraining removes the replay entirely.

The problem it removes: a leaked access token used from an attacker's host — the most common API breach in open banking.
Why minutes, not hours: revocation propagates in the natural expiry window, so a compromised client is contained in minutes without a global token flush.
The ceiling is enforced for finance tenants and is not configurable upward — posture you can't accidentally weaken.

≤ 5 min

Access-token lifetime

Hard ceiling enforced for finance tenants — not configurable upward.

mTLS-bound

Sender-constrained

Bound to the client cert (RFC 8705); a replayed token is rejected.

Rotated

Refresh on demand

Clients re-mint frequently; revocation takes effect in minutes.

Same SDK, different token

What a bank actually receives.

No new integration. Same platform, same SDK — flip the finance module and the access token a bank receives is materially different from a standard one: asymmetrically signed, bound to a certificate, short-lived, and carrying the SCA result and payment context inline so the resource server can authorise the call without a second round-trip.

Standard access token

{
  "alg": "RS256",
  "iss": "https://id.authfi.io/acme",
  "sub": "usr_8f3a...",
  "aud": "api://acme",
  "scope": "openid profile email",
  "exp": 1700003600   // +24h
}

Finance / FAPI access token

{
  "alg": "PS256",                     // asymmetric only
  "iss": "https://id.authfi.io/bank",
  "sub": "usr_8f3a...",
  "aud": "api://bank",
  "acr": "urn:openbanking:psd2:sca",  // SCA performed
  "cnf": { "x5t#S256": "9f86d0..." }, // mTLS cert-bound
  "authorization_details": [          // RAR payment consent
    { "type": "payment_initiation",
      "amount": "250.00 EUR",
      "creditor": "Acme Ltd" }
  ],
  "exp": 1700000300   // +5 min
}

RS256 → PS256 · 24h → 5 min · bearer → cert-bound · plus acr SCA and authorization_details.

PSD2 · dynamic linking

One authorisation. One payment. No reuse.

PSD2 RTS Article 5 demands dynamic linking: the authentication code a customer generates must be specific to the exact amount and payee they saw, and any change to either must invalidate it. A TPP carries the payment in a Rich Authorization Request (RFC 9396); AuthFI runs Strong Customer Authentication, then mints the authorisation code over those precise authorization_details — so the consent is cryptographically pinned to "€250.00 to Acme Ltd" and is worthless for any other transaction.

TPP requests payment authorisation (RAR)

POST /authorize  (Rich Authorization Request, RFC 9396)
authorization_details=[{
  "type": "payment_initiation",
  "amount": { "currency": "EUR", "value": "250.00" },
  "creditor": { "name": "Acme Ltd", "iban": "DE89..." }
}]

Strong Customer Authentication

AuthFI -> user: approve payment of EUR 250.00 to Acme Ltd
acr = urn:openbanking:psd2:sca
-> passkey / app approval (two-factor, dynamic-linked)

SCA bound to amount + payee

{
  "acr": "urn:openbanking:psd2:sca",
  "cnf": { "x5t#S256": "<client-cert-thumbprint>" },
  "authorization_details": [ { "amount": "250.00", "creditor": "Acme Ltd" } ]
}

Short-lived, cert-bound token issued

access_token: eyJhbG...  (expires_in: 300)
token bound to TPP mTLS cert -> single payment only

KYC / AML orchestration

Verification gates issuance. Documents never land here.

Identity proofing is a regulatory obligation, but holding scans of passports and proof-of-address makes you a breach target and a data-residency problem. AuthFI orchestrates the verification step and gates token issuance on the outcome — pass / fail / risk — while the documents stay with your provider. The decision is computed server-side and never serialised into a token, keeping AML signals out of anything a relying party could log.

Bring your provider

Jumio, Onfido, or Sumsub. AuthFI orchestrates the verification step and gates token issuance on KYC status — without storing the documents.

Status, not PII, in the flow

KYC outcome and AML risk are evaluated server-side. They drive the decision but never land in the access token.

Activation gating

A bank cannot go live until ValidateConfig passes: Open Banking standard, KYC provider, and SCA policy must all be set.

Client auth

private_key_jwt / mTLS

Signing

PS256 / ES256

Token binding

x5t#S256 (RFC 8705)

Audit

1 row per decision

Regional regimes

One profile. Every Open Banking regime.

PSD2, UK Open Banking and the Berlin Group all settle on the same FAPI 1.0 Advanced security profile — which is exactly why AuthFI implements the profile once and conforms to it across each regional regime, rather than maintaining a fork per market.

Standard	Region	Profile
PSD2 (RTS / SCA)	European Union	FAPI 1.0 Advanced
UK Open Banking 3.1	United Kingdom	FAPI 1.0 Advanced
Berlin Group NextGenPSD2	EU / EEA	FAPI 1.0 Advanced

Plus the platform you already get: passkeys/MFA, risk & fraud detection, tamper-evident audit, FGA, and SDKs in seven languages.

Get started

Ready to get started?

Free for 5,000 monthly active users. No credit card required.