Open Banking Consent as a First-Class State Machine
Listen to this article
Preparing audio…
FinTech Engineering
I start with the authorization the user actually granted: scope, purpose, actors, time, and terminal states. I do not reduce open-banking consent to customer_consented = true.
State the jurisdiction before the schema
Consent semantics differ across UK Open Banking, EU payment-services rules, UAE Open Finance, and other ecosystems. This article uses the UK Open Banking Implementation Entity (OBIE) Read/Write API v3.1.2 as a concrete engineering example; it is not a universal legal model.
The OBIE Account Access Consents specification defines a consent resource with permissions, creation and status-update timestamps, optional expiration, and states including AwaitingAuthorisation, Authorised, Rejected, and Revoked. It also defines POST, GET, and DELETE behavior. The related Read/Write API Profile explains that an intent carries fine-grained permissions beyond coarse OAuth scopes.
Those versioned specifications support the architecture below. They do not settle what counts as legally valid consent in another jurisdiction; product, compliance, and legal owners must map the applicable rules.
Consent, authorization, and tokens are different objects
A third-party provider can create an account-access consent describing requested permissions and expiry. The bank authenticates the payment-service user and asks them to authorize that intent. Only then does the consent become Authorised. An OAuth authorization code and resulting access token let software exercise the authorization.
Here is how I would keep the boundaries visible:
- Consent resource: who requested what, for which purpose and accounts, under which policy/version, and in which lifecycle state.
- Authorization session: evidence of user authentication, disclosure presented, selections, and the authorization result.
- Access/refresh tokens: technical credentials with audience, scope, sender constraint, and expiry.
- Resource server decision: evaluates the current consent, token, account entitlement, and policy for each request.
A token can expire while a long-lived consent remains authorized; OBIE v3.1.2 explicitly describes this separation. Conversely, revocation should make further resource access fail even if a token’s cryptographic expiry is later.
Use a real state machine
Create the consent in AwaitingAuthorisation. From there, a successful user journey moves it to Authorised; rejection moves it to Rejected; cancellation or timeout follows the adopted profile. Rejected and Revoked are terminal in the cited OBIE profile. Never move a revoked record back to authorized; create a new consent with new evidence.
Make transitions conditional and atomic. Store status, status_updated_at, version, and an append-only transition log. A concurrent revocation and data-access request must resolve against a declared consistency rule. For high-value access, the authorization decision should read current consent state strongly enough that a completed revocation cannot be ignored by a stale cache.
Consent expiry is a scheduled transition or an evaluated condition, not a nightly cleanup detail. Record the exact instant and time zone, and test access at the boundary.
Model scope as data, not prose
Permissions need machine-enforceable identifiers. Bind the consent to the authorized accounts or selection rule, data clusters, transaction-history window, expiry, requesting party, bank, and user. Store the disclosure/policy version and a hash or immutable reference to what was shown.
Purpose can be legally significant but difficult to enforce technically. Keep it explicit and use it in downstream policy, monitoring, and audit. Do not assume an OAuth scope such as accounts captures account selection, date limits, or purpose.
For security-sensitive financial APIs, the OpenID Foundation’s FAPI 2.0 Security Profile defines protections such as sender-constrained access tokens. It reached Final status on 20 February 2025. Adoption still depends on the ecosystem profile; cite the version actually implemented.
Revocation is an end-to-end operation
Revocation must update the consent authority, invalidate or block tokens as required, clear caches, stop scheduled collection, and propagate to downstream data products. The OBIE consent specification says that when a user revokes through the third party, that party calls DELETE on the consent resource before confirming revocation.
Keep evidence of the revoked resource and transition even if the API presents deletion semantics. Data already collected has a separate retention and deletion policy; revoking future access does not automatically define how prior records must be handled.
Test the uncomfortable cases
Exercise authorization abandonment, user rejection, partial account selection, consent expiry during token refresh, revocation concurrent with data retrieval, duplicate callbacks, clock skew, third-party certificate rotation, and a downstream job running from cached permission data.
An auditor should be able to answer: what was requested, what was shown, who authorized it, which accounts and data were included, which policy applied, when access occurred, and why it stopped. Do not log raw credentials or unnecessary personal data to achieve that evidence.
Operational measures include authorization completion, rejection, revocation propagation time, access denied by reason, expired-consent use attempts, stale-cache detections, and downstream jobs stopped after revocation.
The engineering rule
My design rule is to make consent a first-class domain aggregate and let tokens reference it. I evaluate both on protected access, preserve transition evidence, and qualify the model by jurisdiction and specification version. A boolean can say “yes”; it cannot explain what was authorized or which system must stop when the answer becomes “no.”
Before launch, walk one consent through authorization, data access, token expiry, re-authentication, user revocation at each channel, and downstream deletion or retention handling. Confirm that policy and customer wording match the implemented state machine. Repeat the review when the jurisdiction, profile version, requested data cluster, or third-party role changes; those changes can alter both the contract and the evidence required.
Related reading
- Double-Entry Ledger Architecture for Product Engineers
- Idempotency at Scale: More Than a Request Header
What decision would you make?
Add a question, a field note, or a respectful counterpoint. Comments are for signed-in members so the discussion stays useful and professional.