One Confirmation of Payee endpoint per bank, answering for every account
An IBAN carries a bank code, not a segment, so POST /discovery can only send a Confirmation of Payee check to one of a bank’s instances — and a payee whose account sits on another estate comes back “IBAN not recognised”. This proposal fixes that at the LFI: each bank nominates one CoP instance per bank code, and that instance answers for every account under the bank code. Discovery keeps returning a single endpoint, and TPPs change nothing.
Cast your vote
Sign in with the Trust Framework to vote — For, Against, or Abstain — recorded in the open with your reasoning. Your organisation and name come from your directory profile, and each person may vote once. Three questions are attached to this vote — set out in section 07 below. The first two, addressed to LFIs, tell us how much of the ecosystem already conforms and how much work the rest is facing; the third asks TPPs and LFIs whether an account-type alternative would work.
The problem OFP-013 raised still needs solving
OFP-013 set out a gap in Confirmation of Payee: a check against a real, active account can come back “IBAN not recognised” because discovery of the IBAN returned the wrong segment (API Hub) for the bank. Its recommendation was not accepted, but the gap remains — and so does the risk that payers are warned about accounts that would have matched. This proposal takes a different approach to the same problem.
The cause is in how a check finds its bank. The payee is not the TPP’s customer, so the destination IBAN is the only input, and POST /discovery turns it into the API Hub to send the check to. The IBAN identifies the bank, but not whether the account is retail, SME or corporate — and many banks are onboarded with a separate API Hub for each. Discovery only returns one API Hub. If that API Hub’s cop-query searches only its own accounts, a payee held anywhere else in the bank is reported as not recognised:
# Today — one bank code resolves to one instance, which sees one estate
POST /discovery
{ "Data": { "SchemeName": "IBAN", "Identification": "AE070331234567890123456" } }
200
{ "Data": { "DiscoveryEndpointUrl": "https://auth1.bank-retail.apihub.openfinance.ae/.well-known/openid-configuration",
"ResourceServerUrl": "https://rs1.bank-retail.apihub.openfinance.ae" } }
POST https://rs1.bank-retail.apihub.openfinance.ae/open-finance/confirmation-of-payee/v2.1/confirmation
-> cop-query at bank-retail searches the retail core only
204 # "IBAN is not recognised"
# The account is real. It sits on the corporate core, which the retail
# instance's cop-query never looks at.The 204 is indistinguishable, to the TPP and to the payer, from a mistyped or fraudulent IBAN — the very outcome Confirmation of Payee exists to identify.
- The fan-out was rejected.OFP-013 proposed returning every instance from
/discoveryand having the TPP try each in turn. It closed with three votes for and five against. LFIs objected to multiplying CoP traffic by the number of instances they run, and both LFIs and TPPs to paying for every leg that missed. - Several LFIs already answer for the whole bank. One LFI told us its CoP lookup already searches every segment of its accounting platform, so its responses reflect the full stack, not one estate. Another runs a single core for every segment, so every one of its instances would give the same answer. For these banks, fan-out adds load and cost and finds nothing new.
- The fix belongs where the knowledge is. Only the LFI knows which of its estates holds an account. Asking the TPP to guess (an account-type hint) or the Hub to try every option (fan-out) works around a question the LFI can answer directly.
- Resolution must follow the bank code, not the organisation. One vote noted that discovery currently resolves by organisation rather than by brand. Where one organisation operates several brands, each with its own bank code, the check must reach the brand that issued the IBAN.
One bank code, one CoP instance, every account
Each LFI nominates exactly one Confirmation of Payee instance for each bank code it issues IBANs under. The Hub resolves the IBAN to its bank code, as it does today, and returns the nominated instance — the same single DiscoveryEndpointUrl and ResourceServerUrl the response carries now.
The nominated instance answers for every account under that bank code. Its POST /customers/action/cop-query resolves the IBAN wherever the account is held — retail, SME, corporate, a separate brand on a shared bank code, or an estate part-way through a migration. How it reaches those accounts is the LFI’s internal design.
# Proposed — the same request, the same response shape
POST /discovery
{ "Data": { "SchemeName": "IBAN", "Identification": "AE070331234567890123456" } }
200
{ "Data": { "DiscoveryEndpointUrl": "https://auth1.bank-retail.apihub.openfinance.ae/.well-known/openid-configuration",
"ResourceServerUrl": "https://rs1.bank-retail.apihub.openfinance.ae" } }
# bank-retail is the instance this bank nominated for its bank code.
POST https://rs1.bank-retail.apihub.openfinance.ae/open-finance/confirmation-of-payee/v2.1/confirmation
-> cop-query at bank-retail resolves the IBAN across every estate
under the bank code: retail, SME, corporate
200 { "Data": { "NameMatchIndicator": "ConfirmationOfPayee.Yes" } }
# One discovery call, one confirmation call, one charge.
# A 204 now means the bank does not hold the account — not that one
# estate does not.The result is authoritative either way. A 200 with ConfirmationOfPayee.Yes, Partial or No is final, as today. A 204 now means the bank does not hold the account, not that one of its estates does not — so the TPP can report “not recognised” with confidence, and there is no inconclusive state to explain to the payer.
Nothing changes for the TPP. One discovery call, one token, one confirmation call, one charge — the flow every Confirmation of Payee integration is already built against.
The rules
The requirement sits on the bank code, not on any segment taxonomy, so it covers every reason one bank code maps to more than one instance.
- An LFI MUST nominate exactly one CoP instance per bank code. The nominated instance MUST serve Confirmation of Payee and advertise the
confirmationAPI family. An LFI with a single instance nominates that instance; there is no special case. - The nominated instance MUST answer
cop-queryfor every account under the bank code, whatever segment, brand, product line or core platform holds it. Returning204for an account the bank holds on another estate is non-conformant. - The Hub MUST return the nominated instance for every IBAN carrying that bank code, and MUST resolve on the bank code rather than on the organisation. Where one organisation holds several bank codes, each resolves to its own nomination.
- A
204is authoritative for the bank. It states that the bank does not hold the account. A4xxor5xxremains a failure to answer, reported to the payer as could not verify, as today. - Other instances are not routed to. An LFI’s non-nominated instances MAY keep their own CoP endpoints, but discovery never returns them, so there is exactly one place a check for a given bank code can land.
- No change to the TPP-facing API. The
/discoveryrequest and response, the/confirmationrequest and response, and the match indicators are all unchanged. One payee check remains one chargeable call. - No change to the Ozone Connect contract.
cop-querykeeps its request and response schemas; what changes is the population of accounts the nominated instance answers for. - Out of scope: every other flow. Data Sharing and Service Initiation select an authorisation server with the customer’s involvement, so segmentation is already handled there. Insurance is unaffected.
What changes
No schema changes. The work is a nomination for every LFI, a lookup across estates for the LFIs that split them, and routing by bank code at the Hub. TPPs change nothing.
- LFI — nominate, and answer for the whole bank code. Every LFI nominates one instance per bank code. An LFI whose CoP lookup already spans every estate, or that runs one core for all of them, has nothing further to build. An LFI with separate cores extends the nominated instance’s
cop-queryto resolve accounts held on the others. - API Hub — route by bank code. Hold the nomination per bank code and return it from
/discovery, replacing today’s resolution by organisation. - TPP — nothing. No parsing change, no retry logic, no new reporting rule.
Keep AEConfirmationDiscoveryResponse.Data as the single AEConfirmationSourceProperties object it is in V2.1. The V2.2-rc2 draft currently carries Data.ConfirmationSource as an array, from the OFP-013 work; that change is reverted. Add normative text to the /discovery description stating that the endpoint returned is the bank’s nominated instance and answers for every account under the bank code. Targets V2.2.
Add the conformance requirement to the POST /customers/action/cop-query description: the nominated instance MUST resolve any account under its bank code, and MUST NOT return 204 for an account the bank holds on another estate. The request and response schemas are unchanged.
Capture the nomination: for each bank code, the authorisation server whose instance answers Confirmation of Payee. Single-instance LFIs default to their only instance. Multi-instance LFIs confirm their choice as part of onboarding, and again whenever an instance is added or retired.
Resolve the IBAN’s bank code to the nominated instance and return it. This replaces resolution by organisation, which today can send a brand’s IBANs to a sibling brand’s instance.
Update the Confirmation of Payee API Guide to state what a 204 now means, and the LFI implementation guide to set out the nomination and the whole-bank-code requirement. Record the change in the version changelog.
Add a Confirmation of Payee scenario that sends test IBANs from every estate under the bank code — retail, SME, corporate, and any other brand or platform — to the nominated instance, and asserts a 200 for each. This is the only place a nomination that cannot see every account would be caught.
Non-breaking, and never worse than today
No response shape changes, so there is no version migration for TPPs. The new obligation falls on LFIs, so conformance is set at V2.2.
- Nominations can be taken now. They are directory data, not a release. For an LFI that already answers for the whole bank code, nominating ends the false negatives the day the Hub routes to it.
- Split LFIs conform by V2.2. Until they do, the Hub keeps returning the instance it returns today, so a payee on an unreached estate gets the same
204as now. The proposal never makes a check worse. - TPPs are unaffected at every step. The V2.1 and V2.2
/discoveryresponses are identical, so no TPP has to move to benefit.
Other ways to find the right estate
Each of these routes around the LFI. Each puts the cost of a split estate on someone who does not know where the account is.
Discovery returns an array and the TPP tries each entry until one answers. It needs no LFI work, but multiplies CoP traffic at every multi-instance bank, charges for every leg that misses, and adds an inconclusive outcome TPPs must report correctly. It was voted down for exactly those reasons, and for LFIs that already answer for the whole bank it buys nothing.
The TPP makes one call; the Hub tries each instance’s cop-query in turn and bills once. It fixes the charging and spares TPPs any change, but leaves the load on LFIs untouched — the objection LFIs raised first — and makes the Hub responsible for interpreting a sequence of 204s.
The LFI exposes an endpoint that maps its IBANs to the estate holding them, and the Hub calls it before answering /discovery. Accurate, but it adds a new endpoint to every LFI and a new hop to every check. Once an LFI can work out which estate holds an account, it can just as well answer the check itself — which is what this proposal asks for.
AccountType to /discoveryThe TPP sends AccountType alongside the payee’s IBAN in POST /discovery, using the existing Retail, SME and Corporate values already defined for account information. The Hub uses the bank code, the account type and the supported API version to identify a single eligible Confirmation of Payee instance, and returns its DiscoveryEndpointUrl and ResourceServerUrl — the existing single-object response.
If AccountType is missing or invalid, or the mapping does not resolve to exactly one eligible instance, the Hub returns a discovery error. It does not select a default endpoint or return several endpoints.
This avoids routing-related fan-out, and with it unnecessary CoP calls and the transaction costs they carry. However, it requires the TPP to know the payee’s account type and the bank to maintain accurate routing mappings. It cannot serve a check where the account type is unknown, or where more than one instance serves the same account type. The /confirmation contract is unchanged.
Three questions, asked with the vote
These appear as optional boxes when you confirm your vote. The first two are addressed to LFIs: the answers tell us how much of the ecosystem already conforms, and what the rest have to build. The third asks TPPs and LFIs whether the account-type alternative is workable.
Does one of your Confirmation of Payee instances already answer cop-query for every account under your bank code, across every segment and core platform? If not, which estates does it miss, and what would it take to reach them?
This decides how much of the ecosystem is already conformant. Some LFIs have told us their CoP lookup already spans the full stack; for those, this proposal is a nomination and nothing more. For an LFI whose estates sit on separate cores, the answer sizes the real work — and whether V2.2 is a realistic date for it.
Which instance would you nominate for each bank code you issue IBANs under — and do you operate more than one brand or bank code that discovery must keep apart?
The nomination is keyed on bank code, not on organisation. Where one organisation runs several brands, each with its own bank code, each needs its own nomination — and today’s resolution by organisation is known to get this wrong.
Would you prefer the TPP to supply the payee’s AccountType (Retail, SME or Corporate) in POST /discovery, with the Hub routing to one instance per bank code and account type? TPPs: do you know the payee’s account type at the point of a check? LFIs: could you keep an accurate account-type routing map?
This is alternative 04 in section 06. It avoids fan-out without asking split LFIs to build a lookup across estates, but it only works if TPPs know the payee’s account type and LFIs can say which instance serves each one. The answers tell us whether it is a workable alternative to a single nominated instance.
What a single nominated instance buys
- ✓It answers every objection raised against OFP-013. No fan-out, so no multiplied load on LFIs; one call per payee check, so one charge; and no new behaviour for TPPs to build or get wrong.
- ✓Nothing changes for TPPs. /discovery still returns one endpoint, /confirmation is unchanged, and every existing Confirmation of Payee integration keeps working exactly as it does today.
- ✓A 204 means what it says. Because the nominated instance answers for the whole bank code, “IBAN not recognised” is a statement about the bank rather than about one estate — there is no inconclusive state for a TPP to interpret or a payer to misread.
- ✓Many LFIs are already conformant. Banks whose CoP lookup already spans every segment, or that run one core for all of them, need only confirm which instance to nominate.
- ✓The work lands where the knowledge is. Only the LFI knows which of its estates holds an account; the proposal asks it to answer that question internally rather than asking the Hub or the TPP to guess.
- ✓It also fixes splits that have nothing to do with segment — a digital brand alongside its parent, or an estate part-way through a core migration — because the requirement is on the bank code, not on any segment taxonomy.
What it costs
- ×The work falls entirely on the LFIs with split estates. Where retail, SME and corporate accounts sit on separate cores, the nominated instance needs a lookup that reaches all of them — a real integration, not a configuration change.
- ×Until a split LFI conforms, its non-retail payees still come back “not recognised”. The proposal makes no ecosystem-side workaround for that gap; it is closed only when the LFI is.
- ×The nominated instance becomes a single point of failure for Confirmation of Payee across the whole bank code. An outage there stops every check against that bank, where today only one estate’s checks would fail.
- ×Some LFIs keep segments apart deliberately, for data-segregation or operating-model reasons. Answering a name match across segments from one instance may need internal sign-off before it can be built.
- ×There is no fallback by design. If an LFI nominates an instance that cannot in fact see every account, nothing in the protocol reveals it — only functional certification, with test accounts drawn from every estate, would catch it.