Open banking consent management: an enterprise architecture

An Account Information Service can create value in seconds. A customer connects an account, authenticates with their bank and allows a platform to retrieve balances or transactions. The resulting connection may then support onboarding, affordability, reconciliation or financial insight for months.

That long-running service depends on more than the initial consent screen. The platform needs to know which data the customer agreed to share, which accounts the bank authorised, whether access remains permitted, when reconfirmation is due, what happens after revocation and which evidence must be retained.

Open Banking Limited's (OBL) current Data Management guidance follows this complete path from product set-up through consent management, revocation and customer off-boarding. It describes good practice and signposts underlying requirements while making clear that the document itself does not create new legal obligations.¹ An enterprise architecture should preserve those distinctions and turn the customer's authority into a dependable operating control.

Treat consent as a service lifecycle

Consent begins before the redirect to a bank. The platform must define the purpose of the service, the data required, the period of access, any onward sharing and the outcome the customer receives. Those terms form the business contract that later access decisions need to enforce.

The lifecycle continues through several events:

• the customer agrees to a specific Account Information Service and data scope;
• the bank authenticates the customer and authorises access to selected accounts;
• the platform or its provider obtains the credentials needed to request data;
• scheduled and on-demand access occurs within the agreed scope;
• the customer reviews and reconfirms the connection;
• the customer, bank or platform ends access;
• retained data follows the applicable deletion, audit and legal policy.

Each event can succeed, fail, expire or arrive late. A customer may revoke access at the bank while the platform still shows the connection as active. A reconfirmation may complete in the application while a provider token has become unusable. An account may close while other accounts under the same customer relationship remain available.

Design the lifecycle as an owned service with explicit states, evidence and recovery. The customer-facing work on reducing consent fatigue remains important, and the operating architecture determines whether the promise made on those screens is honoured afterwards.

Keep three records separate

A robust model separates three related records.

The customer consent record captures what the customer agreed with the Account Information Service Provider (AISP). It should include the purpose, requested data clusters, duration, connected accounts, customer-facing terms, confirmation evidence and the dates for expiry and reconfirmation.

The bank authorisation record captures the account-access-consent resource and the accounts selected in the account servicing payment service provider (ASPSP) domain. In version 4.0.1 of the Open Banking Read-Write API, the resource supports creation, status retrieval and deletion. It includes an identifier, permissions, dates, status and status-reason fields.²

The data-processing record captures what data was retrieved, where it was stored, which downstream services received it and which retention or deletion policy applies. The lawful basis for processing personal data may require analysis beyond the payment-services consent. Open Banking guidance explicitly warns that these concepts should be handled with care.¹

Link the records through stable identifiers while retaining their separate meaning. A valid provider token cannot establish that the customer has reconfirmed consent. A current customer consent cannot prove that the bank-side resource remains usable. A revoked connection does not answer every question about data already obtained.

This separation improves auditability across customer journeys. An investigator can trace a data request to the current customer authority, bank resource, provider credential, purpose and downstream use from the stored evidence.

Build a canonical consent ledger

The consent ledger should be the platform's authoritative view of whether an Account Information connection may be used. Store each connection as a versioned record with its complete change history.

A useful ledger entry includes:

• customer, organisation and service identifiers;
• AISP, agent, technical provider and ASPSP identifiers;
• the bank-side consent identifier and API version;
• requested permissions and the customer-facing data clusters;
• selected accounts, where the platform can identify them;
• purpose, duration and onward-sharing terms;
• customer grant, bank authorisation and reconfirmation timestamps;
• consent expiry, reconfirmation due date and last successful data sync;
• current customer, bank, credential and access states;
• revocation source, reason, timestamps and recovery state;
• retention class, deletion outcome and supporting evidence.

Record changes as events with an actor, source, effective time and observed time. This matters when a bank event arrives after a scheduled poll or when a provider reports an earlier effective cancellation. Retaining both times lets the platform decide which requests were permitted and identify data retrieved during a disputed interval.

Permissions also need versioning. A request for new data elements should create a new consent process because the current Open Banking customer guidance says the specific elements of an existing consent cannot be edited through the API.³ Preserve the previous authority for audit and prevent the new request from inheriting access before customer and bank approval complete.

Gate every data access from current state

Every scheduled refresh, customer-triggered request and downstream data job should pass through the same access decision. The decision should evaluate the service purpose, customer consent, reconfirmation date, bank resource, provider credential, account scope and requested data permissions.

Use an explicit decision result such as `allowed`, `reconfirmation_required`, `bank_reauthentication_required`, `revoked`, `expired`, `credential_unavailable` or `manual_review`. Include the reason and evidence used. Downstream services should receive the decision and a bounded data result, with no direct authority to bypass the consent layer.

The access boundary also needs a freshness policy. A balance or transaction dataset may remain available after a connection pauses, although it becomes older with every hour. Mark the retrieval time and connection state with the data so a lending, reconciliation or support system can decide whether the information remains suitable for its purpose.

Unknown states should stop new retrieval and enter an owned exception queue. Permissive mapping is especially dangerous around cancelled or expired connections. The current v4.0.1 specification includes status reason fields because the same high-level state can arise through different operational events.² Keep the raw provider and bank evidence beside the normalised result.

Run 90-day reconfirmation as a scheduled workflow

The Financial Conduct Authority expects an AISP to reconfirm at least every 90 days that the customer continues to consent explicitly to access. When the customer has not reconfirmed, the AISP must stop accessing account information. Access may resume after a later reconfirmation.⁴

The reconfirmation date and the consent expiry date describe different controls. A long-lived consent can remain capable of reconfirmation while data access is paused. Routine reconfirmation at the AISP also differs from re-authentication at the bank. The FCA strongly encourages ASPSPs to rely on the applicable Strong Customer Authentication exemption unless they have proportionate and objective reasons to require authentication, such as suspected fraud or unauthorised access.⁴

Build reconfirmation as a durable workflow:

1. calculate the due date from the last valid confirmation and the applicable policy;
2. notify the customer with enough time to act and show the accounts, purpose, permissions and consequences;
3. present continue and discontinue choices with equal prominence;
4. record the customer's decision and the exact consent version reviewed;
5. pause access at the deadline when confirmation is absent;
6. resume only after a valid later reconfirmation and a fresh access decision.

The current AIS Consent Dashboard guidance says the dashboard should display the reconfirmation date, last sync time and an active or reconfirm status. It also requires the AISP to stop access after the 90-day point when consent has not been reconfirmed.³ Use these fields as projections of the ledger so the customer, support team and scheduler see the same state.

Model accounts and providers explicitly

The FCA says a single reconfirmation may cover more than one linked account when the customer is clearly consenting for multiple, specifically identified accounts. It also recognises that an AISP may synchronise reconfirmation dates across accounts added at different times.⁴

That flexibility still requires account-level evidence. Keep the customer relationship, consent, bank connection and individual account as separate entities. One customer may connect several banks, each bank may expose several accounts and each connection may have a different credential, status or reconfirmation date.

Decide how synchronisation works before offering one customer action. The workflow can align several connections to the date of the latest confirmation, provided the customer sees the full scope and the ledger records which accounts were covered. A failed reconfirmation for one bank should not corrupt a successful decision for another. Return a clear result for every connection and let the customer retry the unresolved part.

Agents and onward-sharing arrangements add another layer. The current guidance requires clarity about the customer-facing organisation, the regulated AISP and other parties receiving data.¹ Treat each relationship as part of the consent scope and provider inventory. A change in agent, purpose or recipient can require customer communication, contract review or a new consent path.

Make revocation atomic and recoverable

Revocation crosses several systems. The customer can act in the AISP service or at the bank. The platform needs to stop retrieval immediately, update the provider or bank resource, confirm the result to the customer and apply its policy to previously obtained data.

For revocation initiated with the AISP, the v4.0.1 specification says the AISP must delete the account-access-consent resource with the ASPSP as soon as is practically possible.² The customer-experience guidance also expects an easy cancellation path and a clear explanation of the service consequence and treatment of existing data.³

Use a workflow with a durable revocation intent. The first committed action changes the platform's access decision to `revoked_pending_bank`, which blocks new requests. A worker then calls the provider or ASPSP deletion path using an idempotent operation where the provider supports one. Success changes the bank-resource projection to deleted and permits final customer confirmation.

A timeout creates an unknown result. Keep access blocked, retry safely, query current state where possible and alert an owner when uncertainty remains. The customer-facing message can confirm that the platform has stopped its own access while describing any remaining bank-side update accurately.

Bank-initiated cancellation needs event and polling coverage. The specification's `CANC` state can represent customer cancellation through the ASPSP dashboard or bank suspension of the access token.² Preserve the reason, stop access and route the customer to an appropriate reconnect or support journey.

Control dormant connections and off-boarding

Current Open Banking good practice recommends considering proactive deletion when a customer has not reconfirmed for some time and re-engagement is unlikely. It also says customers should be able to leave a service easily, understand what happens to their data and expect data that is no longer needed to be deleted.¹

Translate that guidance into a documented policy with defined states and owners. A useful progression may include `reconfirmation_overdue`, `dormant`, `scheduled_for_closure` and `closed`. Define how long each state lasts, which notifications occur, whether any service features remain available and who approves exceptions.

Keep access authority separate from retention authority throughout off-boarding. Revocation stops new retrieval. Previously obtained data then follows the retention class attached to its purpose, legal basis and audit needs. Record what was deleted, retained, pseudonymised or transferred, together with the rule and effective date.

When data has moved to downstream systems, deletion orchestration needs a complete consumer inventory. Send versioned deletion requests, collect acknowledgements and reconcile failures. Analytics stores, support exports and derived decision records may need different treatment, so the policy must identify them before a customer closes the service.

Measure consent operations and test failures

Consent management needs service-level indicators. Measure grant completion, bank-authorisation success, reconfirmation completion, connections paused at deadline, revocation completion time, bank-state mismatches, dormant connections, deletion exceptions and customer contacts by provider and ASPSP.

Review comprehension as well as technical completion. Open Banking good practice recommends management information and regular testing of consent journeys with customers.¹ A high confirmation rate can still hide unclear language or an unbalanced choice. Combine funnel data with research, complaints and support evidence.

Test failure sequences in a controlled environment:

• the customer reconfirms while the provider credential has expired;
• the bank cancels one account within a multi-account relationship;
• a revocation request times out after the bank has applied it;
• a provider sends duplicate or delayed cancellation events;
• the reconfirmation scheduler fails before a deadline cohort;
• a downstream data consumer rejects a deletion request;
• an API version migration changes consent status codes or reason fields.

Every scenario needs an expected ledger state, customer message, retry policy, alert, owner and recovery test. The Open Banking API version migration runbook provides the wider change discipline for keeping consent meaning stable across interface releases.

Hold providers to an evidence contract

An enterprise buyer should ask its Open Banking provider to expose the information required to operate this model. That includes stable consent identifiers, raw and normalised states, status reasons, token and account scope, last data retrieval, reconfirmation support, revocation behaviour, event delivery, polling fallbacks and version history.

Agree ownership for every transition. The provider may manage bank connectivity while the enterprise owns customer communication and product access. The regulated AISP may hold the formal consent relationship while an agent delivers the customer-facing service. The operating model should name the actor, evidence and escalation path for each step.

Contract and service reporting should cover revocation latency, event retry policy, data export, deletion support, incident communication and exit portability. The provider should be able to demonstrate how a connection moves from grant through closure and how the enterprise can retrieve the evidence after a dispute, migration or supplier change.

These expectations build on the operational value of shared Open Banking standards. Standards define common resources and journeys. Enterprise delivery depends on consistent implementation, visible exceptions and accountable recovery.

Operate consent as infrastructure

Open banking consent management connects customer choice to every later data request. The safest architecture gives that authority one canonical ledger, enforces it at the access boundary and retains the separate records needed for bank authorisation and data processing.

The practical pattern is clear: define the purpose, version the consent, link bank resources, gate each access, schedule reconfirmation, preserve account-level scope, make revocation recoverable, close dormant connections and reconcile downstream data handling. Measure each transition and require providers to expose the supporting evidence.

An enterprise team should be able to answer which customer authority permitted a specific data request, which account and bank resource it used, when that authority was last confirmed and how access and retained data were handled after the relationship ended. That answer is the real output of a well-designed consent architecture.

Footnotes

1. Open Banking Limited, Data Management good-practice guidance, accessed 20 August 2026. Data management
2. Open Banking Limited, Open Banking Read-Write API v4.0.1, accessed 20 August 2026. Account Access Consents
3. Open Banking Limited, Customer Experience Guidelines, accessed 20 August 2026. AIS Consent Dashboard
4. Financial Conduct Authority, PS21/19: Changes to the SCA-RTS and related guidance, December 2021, accessed 20 August 2026. Policy statement
5. Open Banking Limited, Customer Experience Guidelines, accessed 20 August 2026. Consent and Data Sharing Management