
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.

Example: Verifying an Entity Statement (Node.js)
Here's how to verify a signed JWT Entity Statement using the jose
library in Node.js:
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
orjose
- 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.