Cover image for The Rise of Federation in Open Banking: Beyond DCR and Into the Future

The Rise of Federation in Open Banking: Beyond DCR and Into the Future

Federation is gaining traction in Open Banking ecosystems that are looking to scale securely. In this article, we unpack what Federation is, how it differs from Dynamic Client Registration (DCR), who's adopting it, and how fintechs can get ahead of the curve.

Why Federation, and Why Now?

As Open Banking ecosystems mature, the limitations of bilateral relationships between fintechs and banks are becoming more apparent. Dynamic Client Registration (DCR) was a breakthrough, but it doesn't scale gracefully when you're dealing with dozens—or hundreds—of financial institutions.

Enter Federation. Based on OpenID Connect Federation 1.0 (now final), Federation allows a single registration process to be accepted across many banks, simplifying trust, identity, and client onboarding at scale.

What is Federation?

In the context of Open Banking, Federation allows software clients (like fintech apps) to register and be recognised across an entire ecosystem, using a trust framework and signed metadata. Instead of each AS (Authorisation Server) maintaining its own registration portal and DCR endpoint, they trust a central authority—or trust anchor—that distributes signed statements.

This allows third-party providers (TPPs) to authenticate and register with multiple banks without repeating the same process each time.

Federation vs Dynamic Client Registration

Feature Federation DCR
Scalability High – centralised trust Low – 1:1 relationships
Discovery Automatic via metadata Manual or directory-driven
Governance Model Federation Authority (Trust Anchor) AS-level policy
Validation Chain of trust (signed JWTs) Manual or static config
TPP Experience Register once, access many Repeat per bank

Who's Using Federation Today?

  • 🇳🇴 Norway: The OBAPI ecosystem uses Federation with BankID to manage software client identity.
  • 🇧🇷 Brazil: Discussions in Phase 3+ of Open Finance Brasil include moving towards Federation-based registration.
  • 🇪🇺 EU & 🇬🇧 UK: Pilot conversations ongoing within the Open Banking Implementation Entity and Berlin Group.
  • 🌍 FDX: Federation is being explored but has not been formally adopted (yet).

Implications for Fintech Developers

Federation brings smoother onboarding but introduces some new technical expectations. Fintechs need to support:

  • Entity Statements: signed JWTs asserting metadata and identity
  • Trust Chain Resolution: verifying upstream authorities
  • Dynamic metadata fetching via .well-known/openid-federation
  • Understanding new error flows and trust invalidation

Tooling is still evolving, but getting ahead now means less friction later when ecosystems require Federation as standard.

Visual: DCR vs Federation Flows

Use this sequence diagram to compare the two onboarding paths.

Web Sequence Diagram of DCR vs Federation: Registration Flow
View Sequence Diagram (WebSequence format)


title DCR vs Federation: Registration Flow

participant TPP
participant Bank (AS)
participant Directory
participant Trust Anchor

alt Dynamic Client Registration (DCR)
TPP -> Bank (AS): [1] Get config (.well-known)
TPP -> Directory: [2] Get SSA
Directory -> TPP: [3] Signed JWT (SSA)
TPP -> Bank (AS): [4] POST /register\nwith SSA
Bank (AS) -> Bank (AS): [5] Verify JWT, validate claims
Bank (AS) --> TPP: [6] Client ID issued
else OpenID Federation
TPP -> Trust Anchor: [1] Get Trust Chain Metadata
Trust Anchor -> TPP: [2] Signed Entity Statement
TPP -> Bank (AS): [3] Fetch AS metadata\nvia federation
Bank (AS) -> TPP: [4] Return signed config
TPP -> Bank (AS): [5] Request access token
Bank (AS) --> TPP: [6] Access granted (based on federation trust)
end
      

Example: Verifying an Entity Statement (Node.js)

Here's how to verify a signed JWT Entity Statement using the jose library in Node.js:

View Node.js Example

import { jwtVerify, importJWK } from 'jose';

// Example JWK for verification
const jwk = {
  kty: "RSA",
  kid: "12345",
  alg: "RS256",
  use: "sig",
  n: "....",
  e: "AQAB"
};

// Example Entity Statement (JWT)
const entityStatement = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...";

async function verifyEntityStatement(jwt, jwk) {
  const key = await importJWK(jwk, 'RS256');
  const { payload } = await jwtVerify(jwt, key);
  
  console.log('Verified payload:', payload);
  return payload;
}

verifyEntityStatement(entityStatement, jwk).catch(console.error);
      

How to Start Working with Federation

The final version of OpenID Connect Federation 1.0 is available now. You can start experimenting with:

  • Building and signing Entity Statements with node-jose or jose
  • Resolving trust chains with simple JWKS introspection

Closing Thoughts

Federation is not here to replace DCR overnight, but it's an essential evolution. As ecosystems grow, onboarding and trust management need to scale too. For fintechs looking to streamline integrations, Federation is the future—and it's closer than you think.