Open-Banking Consent Is Not Bank Authority. It Is a Revocable Permission With a Data Trail.
A customer can authorize data access or payment initiation without making the third party authoritative about the account, balance or payment result. The discipline is to separate consent, bank execution, API payload and KYC evidence before a revoked permission becomes a quietly stale capability.
The rule
Consent permits access; it does not certify the data, the customer or the payment outcome.
The Consent Screen Has Been Given Too Much Work
Open banking opens with a soothing fiction.
Your customer sees a consent screen, presses a button, and the institution is invited to believe that a difficult set of facts has become one easy fact.
It has not.
The button may permit a third party to request a balance, retrieve a time-bounded transaction feed, or transmit a payment order.
It does not make that third party authoritative about the balance.
Or the account holder.
Or the available funds.
Or the final payment result.
Or the legal person who may disclose a business account.
It certainly does not turn a bank feed into a small self-contained KYC department.
That last ambition has produced some excellent product demonstrations, and later a meeting involving Compliance.
So the useful question is not whether consent is valid in the abstract.
What does this consent permit, for which account, by which third party, for which purpose, until when? And which institution stays authoritative for every fact that follows?
Fussy questions.
They are also the ones that keep your records from becoming optimistic.
Seven Authorities, Not One Convenient App
The layer model is short, which is unfortunate for anybody hoping to solve it with a single field called open_banking_verified.
Identity belongs to KYC evidence and, for the account relationship, to the bank.
FATF’s digital-ID approach asks that the technology, architecture, governance, assurance level, reliability and independence all be assessed in the relevant illicit-finance context.
A selfie and optical character recognition are data capture.
They are not a legal opinion with a friendly user interface.
Consent belongs to your customer and the regulated consent flow.
A valid journey identifies the recipient, the account or data categories, the purpose, the collection period, whether access is one-off or ongoing, and the withdrawal route.
Australia makes the habits explicit.
Consent is voluntary, express, informed, purpose-specific, time-limited and readily withdrawn, and the permitted collection period runs no more than 12 months.
A technical token endures rather more happily than the explanation that created it.
That is not a reason to promote the token.
Account data belongs to the account-servicing bank.
Payment execution belongs to the bank and the payment rail.
Third-party display belongs to the provider, which is authoritative about exactly what it chose to show, when it showed it, and which payload it received.
Revocation belongs to the customer or the bank, under the applicable rules.
Exception reactivation demands a named authorised approver.
Seven different claims.
They should not be made to share a waistcoat.
PSD2 Articles 66 and 67 make the access perimeter specific.
A payer can use a payment-initiation provider, and a payment-service user can use account-information services, where the payment account is accessible online.
That is not a general command to make mortgages, investments, insurance, payroll files or your internal fraud score available to an app with a tasteful gradient.
Nor does non-discrimination in a routing rule require you to approve a suspicious payment.
A Permission Is Not an Instruction
Take an ordinary online invoice.
Your customer chooses pay from bank.
The payment-initiation provider creates a transaction reference, gathers what is needed to route the proposed payment, identifies itself through your approved interface, and sends a bounded request.
It should not receive your customer’s online-banking password.
That is the whole point of replacing credential delegation and screen scraping with a request you can authenticate, log, rate-limit and revoke.
Then you do the jobs no third party can do for you.
Your own customer authentication.
The available-funds check.
The account-status check.
The payment-limit check.
Fraud signals.
Sanctions screening.
Internal controls.
You may reject the instruction because the account is short, the daily limit is reached, authentication did not complete, or your security rules object.
A provider cannot cure any of that with enthusiasm, a better callback, or a particularly persuasive onboarding funnel.
Once authorised, you accept the payment order and return a status.
Under PSD2 Article 66 you make information about initiation and execution available to the provider immediately after receiving the order.
That status may be accepted, pending, rejected or settled.
Four states. Not four brands of paid.
The payment rail, not the consent screen, decides debiting, crediting, clearing, settlement and any recall process.
In Brazil’s open-finance terminology, the payment-initiation provider never holds the transferred funds at any time.
It provides a message path.
Less glamorous, and much more accurate.
A merchant marking the order paid when a browser returns from bank authentication has confused a journey with a result.
The customer’s bank statement, the provider record, the merchant order ledger and the merchant-bank receipt all have to align.
Four records.
One invoice.
No scope for strategic optimism.
Where the bank rejected the order and the merchant marked it paid, the API did not lose money.
The records reported different events, and they need timestamps, authorisation evidence, status messages and the payment-rail rules to be put back in order.
Keep the Ten Records, Not a Heroic Boolean
Do not store consent = true.
Store the ten consent records: customer; account; third party; scope; purpose; grant time; expiry; refresh token; revocation event; payment-execution status.
The list is complete.
Customer identifies whose direction matters.
Account stops a general permission wandering quietly into another one.
Third party identifies the legal recipient, rather than the developer’s API key.
Scope separates balances from transaction history, and a one-off payment from an ongoing connection.
Purpose says why the collection exists at all.
Grant time and expiry make the permission temporal.
The refresh token records the capability used to obtain further access under the arrangement.
The revocation event records who ended the permission, when, and how the future route changed.
Payment-execution status keeps the entirely separate question of a specific order visible.
That compact record is not tidiness for its own sake.
It is the difference between explaining a disclosure and discovering that your only retained evidence is a token that looks faintly familiar.
The wider audit trail wants requests, withdrawals, disclosed data, refused requests, complaints, identifiers, timestamps and software events.
Australian data holders keep records of authorisations, withdrawals, disclosed data, refused requests and complaints, alongside periodic regulatory reports.
A useful five, because it captures the agreeable path and the awkward one. The awkward one is where the system earns its keep.
And do not let a token’s technical validity become a conclusion about authority.
A pre-ticked consent to a year-long feed to improve services fails the stated consent principle even where the token works perfectly.
In the CFPB’s final-rule description, a third party collects, uses or retains personal financial data to supply the product the consumer requested.
Not for unrelated business purposes.
So scope and purpose have to survive transmission.
Storage is cheap.
Explaining an unrelated use is not.
An Account Feed Is Evidence, Not a KYC Verdict
The temptation is understandable.
A bank-connected account has dates, transactions, an account number, perhaps a name, and the distinctly calming smell of an API.
Surely it can settle who your customer is.
No.
KYC begins by defining the legal customer, the relationship type, the product, the jurisdictions, the channel, the people acting for the customer, and the capabilities requested.
A trading name is inadequate where the contracting entity, the director, the account authority and the cash-management relationship sit in different places.
A relationship can span a dozen related accounts.
A consented feed from one of them does not identify the other eleven, establish a director’s authority, or explain the ownership chain.
The same discipline applies to a natural person.
A verified identity record keeps the source response, the verification method, the date and the discrepancy.
A spelling difference from transliteration can be corroborated.
A materially different date of birth, a revoked credential, or a source you cannot independently retrieve creates an exception case.
It does not become bank verified because a balance endpoint happened to answer.
Reconcile the Difference Before It Becomes a Customer Story
An API payload can be accurate and still be operationally wrong for the use you are making of it.
The balance may be stale.
The account scope may be wrong.
The selected account may not be the legal customer’s operating account. You may have changed the status after the payload was sent.
The third party may be displaying a transformed field.
A source refreshed quarterly does not carry the current-status value of a real-time official registry, however identical the company number.
Time is not a decorative field.
So classify your breaks.
Consent scope.
Purpose.
Timing.
Stale data.
Identity conflict.
Representative authority.
Ownership.
Bank rejection.
Payment status.
Revocation propagation.
Field interpretation.
Provider display.
Different cases.
Different evidence, remedies and owners.
A revoked consent that still permits a request is an access-control incident.
A correctly delivered balance that is old is a data-timing issue.
Treating both as an open-banking issue is how a control programme acquires a large miscellaneous drawer.
Your KYC decision controls supply a useful finish.
A case can be low, standard, high or prohibited only where the factors support the label, and the record distinguishes inherent risk from residual risk after controls.
Rejection, deferral pending evidence, restricted approval and full approval are four separate outcomes. No account number, payment limit or credit access should exceed the capability actually approved.
A data-access permission deserves the same respect.
Consent may be current while KYC approval has expired.
Scope may be valid while representative authority is unresolved.
A bank response may be clean while the intended product is not approved.
Not contradictions. Layers doing their jobs.
The Recipient Is a Legal Party, Not an Icon on a Phone
There is a second little merger systems enjoy attempting.
Third-party application, legal recipient, customer representative and account authority all become the person who logged in.
A charmingly economical model, until a business account, a joint account, a delegated employee or a corporate group enters the room.
An access regime identifies the account or data holder, the account type, the permitted third party, the customer whose instruction matters, and the supporting service.
Australia distinguishes a data holder from an accredited data recipient.
The first shares on direction.
The second meets accreditation requirements.
So eligibility attaches to the legal recipient, not to an application developer’s API key.
EU arrangements similarly require participant identity, and permit an account provider to reject a request where a provider seeks a payment capability outside its registration.
Participation controls.
A more grown-up phrase for ensuring that not every website with a convincing logo receives bank data.
Your customer-side authority needs equal care.
An employee may be authorised to make payments and have no authority to disclose the proprietor’s entire financial profile.
Joint-account holders can require an approval before disclosure.
A corporate relationship may have a parent, subsidiaries, signers, beneficial owners and a connected cash-management arrangement.
The group consented is a sentence with the operational quality of a damp receipt.
Revocation Is a State Change, Not a Courtesy Email
For a one-off payment, authority ends when the instruction completes, is rejected, or expires.
For an ongoing connection, revocation changes the future request path.
Australia requires a data holder to act on a withdrawn authorisation promptly, under its regulated timetable.
That rule creates no universal deadline for cancelling a payment order another scheme has already accepted.
A distinction that looks fussy until a customer asks why a revoked data connection did not reverse yesterday’s payment.
Test the route.
Grant consent.
Retrieve within scope.
Narrow the scope.
Expire it.
Revoke it.
Attempt the next request.
Observe the refusal.
Reconcile the retained records.
Then test the inconvenient variants.
A provider outage.
An unavailable dedicated interface.
An invalid certificate.
A malformed field.
An account not accessible online.
A request for a capability outside the provider’s registration.
An EU account provider must offer at least one interface for qualifying providers.
That is an access outcome.
It is not a guarantee that every request succeeds.
A fallback arrangement and a supervisory exemption relieve nobody of explaining what happened to a particular request.
Where reactivation is exceptional, demand the named authorised approver, the evidence, the effective time, the new scope, the expiry and the reason.
Reconsider the KYC record too, where a new owner, director, legal status, product, country corridor, sanctions-list update, expired document or adverse-information result calls the prior conclusion into question.
A missed review is an overdue-control exception, with an owner and an interim treatment.
It is not, regrettably, a form of continuity.
The Ladder, Before Someone Says the App Says It Is Fine
Identity or customer risk?
Go to KYC evidence and the bank.
Consent and scope?
Go to the customer’s regulated consent flow.
Account balance or status?
Go to the account-servicing bank.
Payment execution?
Follow the bank and the payment rail.
What did the provider display?
Inspect the provider record and the API payload.
Revocation?
Follow the customer or bank event through the future request path.
Exception reactivation?
Demand a named authorised approver.
This is not a rejection of open banking.
It is the small discipline that lets open banking be useful, without asking a consent screen to run the bank, close the payment rail, and perform KYC between meetings.
Consent permits access; it does not certify the data, the customer or the payment outcome.
What the paper establishes
- Consent records must retain the customer, account, third party, scope, purpose, grant time, expiry, refresh token, revocation event, and payment-execution status.
- Data access, payment initiation, bank acceptance, and settlement are separate events with different authorities and records.
- A bank remains authoritative for its authentication result, account status, available funds, payment controls, debit record, and payment-rail execution state.
- A third-party API response is dated evidence that must be reconciled to bank-account records before it supports an operational conclusion.
- Consent does not replace KYC evidence about identity, beneficial ownership, representative authority, purpose, or customer risk.
- Revocation must stop future request paths and create a retained revocation record; it does not automatically cancel a payment order already accepted by a payment scheme.
- Stale data, scope errors, identity conflicts, bank rejections, and failed revocation propagation need distinct exception classes and named owners.
Questions
- Does open-banking consent let a third party control the bank account?
- No. Open-banking consent permits a named third party to request specified account data or transmit a specified payment instruction through the applicable access arrangement. The account-servicing bank remains responsible for its own authentication, account status, available-funds checks, payment limits, fraud and sanctions controls, and decision to accept or reject an instruction. Consent is an access boundary, not a transfer of bank authority.
- What has to be stored for an open-banking consent?
- A consent record identifies the customer, account, third party, scope, purpose, grant time, expiry, refresh token, revocation event, and payment-execution status. The record also needs enough request and reference information to connect the consent to disclosures, payment messages, support cases, and audit evidence. A current token without its scope, purpose, time limits, and revocation history is not a defensible consent record.
- Is a payment initiated through open banking already paid?
- No. Payment initiation transmits a customer-requested order; it is not final settlement. A bank can reject an instruction because authentication fails, available funds are insufficient, a payment limit applies, or security controls intervene. An accepted order can still be pending under payment-rail timing. A merchant should reconcile the bank debit, third-party payment record, merchant order ledger, and merchant-bank receipt before treating the invoice as paid.
- Can a third party change the amount or payee after the customer consents?
- Not in the PSD2 payment-initiation model described by Article 66. The payment-initiation service provider must not modify the amount, payee, or another feature of the payment transaction. The bank presents the concrete instruction for its own authentication and controls. A consent to a €143 payment therefore does not give the provider a general authority to alter the order or operate the account.
- Can open-banking data be used as KYC proof?
- Open-banking data can be one input to a KYC assessment, but consent alone does not verify identity, beneficial ownership, representative authority, or customer risk. KYC requires an evidence record with source, verification method, date, discrepancies, and decision. A valid driving licence can establish one claim without establishing a legal entity’s authority; an account-data feed has the same limitation and must be assessed for the claim it supports.
- What happens when a customer revokes an open-banking consent?
- Revocation changes the future request path and creates a revocation record. For ongoing data access, the data holder acts on a withdrawn authorisation under the applicable regime and timetable; Australia’s Consumer Data Right requires prompt action under its regulated timetable. Revocation does not automatically cancel a payment order that a bank has already accepted or that another payment scheme is processing. Those are separate operational states.
- Why is an API balance not the same as the bank balance?
- An API balance is a dated response transmitted under a defined scope, timestamp, field mapping, and service condition. The account-servicing bank’s record is authoritative about the account state it maintains, while the API response is evidence of what the third party received. A discrepancy can result from timing, stale data, scope, field interpretation, an outage, or a rejected request, and requires reconciliation rather than substitution.
- Does an authorised employee have authority to share a business account’s data?
- Not necessarily. Payment authority and authority to disclose the proprietor’s financial profile are separate legal facts. Joint and business accounts require the applicable account mandate, account structure, and access rules to be checked; Australia notes that joint-account holders can require an approval before disclosure. Control of a phone or possession of an application credential does not establish the required disclosure authority.
- How should a bank or provider handle a mismatch between open-banking data and KYC records?
- A mismatch should become a classified exception, not an informal judgment. The case compares the relevant bank response, consent record, customer identity evidence, ownership-and-control map, and the requested capability. A spelling difference may be resolved with corroboration, while a materially different date of birth, an unverified representative, or data inconsistent with the stated relationship purpose requires evidence, a documented decision, restriction, rejection, or escalation.
- What records are needed after an open-banking payment?
- The record retains the payment instruction, transaction reference, consent evidence, bank authentication and status messages, third-party payment record, merchant order record, and merchant-bank or acquirer receipt. These records distinguish initiation, acceptance, rejection, pending processing, debit, credit, and settlement. A redirected browser or merchant confirmation screen is not sufficient evidence of final payment value because the bank and payment rail determine execution.
- How should failed revocation or stale data be handled?
- Failed revocation propagation and stale data should be separate exception classes with a named owner, evidence, containment action, and review. A revoked consent that still permits a request is an access-control problem; an old but correctly delivered balance is a data-timing problem. The distinction directs the remedy: disable future access and investigate propagation for the first case, then reconcile date, scope, and bank records for the second.
- Who can reactivate a revoked open-banking connection?
- Reactivation requires a new or renewed consent record under the applicable access arrangement and a named authorised approver for any exception process. A prior consent and old token do not prove that current scope, purpose, account authority, customer identity, or customer-risk conditions remain valid. The reactivation record should preserve the decision maker, evidence, effective time, permitted scope, and any expiry or restriction.