Need help with your APIs? I offer API discovery, governance & evangelism services. Explore services →
API Evangelist API Evangelist
Discovery
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC

Dynamic Client Registration

Dynamic Client Registration (DCR), defined in RFC 7591 with management operations in RFC 7592, is the OAuth 2.0 and OpenID Connect standard for registering client applications with an authorization server programmatically, over an API, rather than through a manual developer-portal sign-up. In open banking and open finance it lets an accredited third party enroll with each bank's authorization server automatically, presenting an eIDAS or OBIE software statement or certificate, so onboarding scales across many providers without per-bank paperwork.

Dynamic Client Registration (DCR), standardized as RFC 7591 with lifecycle management in RFC 7592, lets a client application register itself with an OAuth 2.0 / OpenID Connect authorization server through an API instead of a human filling out a developer-portal form. The server issues a client_id (and optionally credentials) in response to a registration request, and the client can later read, update, or delete that registration.

  • Onboarding at machine speed - A third party can enroll programmatically, which is what makes an ecosystem of many providers workable — you register with each bank’s authorization server via an API call rather than a manual sign-up per institution.
  • Trust anchored in a software statement - In open banking, the registration request carries a signed software statement or an eIDAS/OBIE certificate that identifies and vouches for the third party, binding the dynamic registration to an accredited identity.
  • Part of the FAPI onboarding stack - DCR sits alongside PAR, private_key_jwt, and mTLS as the enrollment half of the high-assurance profiles open banking and open finance mandate.

DCR is the piece of the stack that decides whether an ecosystem can actually scale to many participants, and it is a useful diligence signal when I score a regulated API: it separates a program built for programmatic, many-to-many onboarding from one that still expects a human to request access per provider. As onboarding shifts from a months-long human process toward the machine-speed enrollment agentic consumption requires, DCR — a scoped credential provisioned in a single round trip — is the standard that models what that future looks like.

Referenced in API Evangelist papers

This standard shows up in my published research. These reports read the machine-readable evidence provider by provider — and put this standard in the context of a real sector.

The State of UK Banking APIs

The programmatic onboarding step behind OBIE enrollment — third parties register with eIDAS/OBIE certificates rather than a manual sign-up.

The State of Australian Banking APIs

Part of the CDR accreditation and client-onboarding stack that gates the consumer data-sharing surface.

Governed by these regulations

A standard is the machine-readable contract; a regulation is the law that requires it. These are the regulations that mandate or drive this standard, catalogued at regulations.apievangelist.com.

Revised Payment Services Directive (PSD2)

Programmatic onboarding for the third parties PSD2 grants account access.

Consumer Data Right (CDR)

Part of the accreditation/onboarding stack that gates CDR consumer-data sharing.