Addressing: Sort Codes, IBANs and Confirmation of Payee

39.0 What this chapter gives you#

1. You will be able to explain why a payment to a valid account in somebody else’s name arrives without a single system in the chain failing.
2. You will be able to take a sort code and account number apart and say exactly what each half addresses, and what neither of them proves.
3. You will be able to run a MOD11 and a DBLAL modulus check by hand, and say why summing the products instead of the digits of the products gives the wrong answer.
4. You will be able to state what a passing modulus check is worth, given that a MOD10 rule admits about one in ten arbitrary numbers and a MOD11 rule about one in eleven.
5. You will be able to generate and validate the two check digits of a British IBAN, and explain why a correctly formed IBAN always leaves a remainder of exactly 1 modulo 97.
6. You will be able to explain why a BIC can never address an account, and why its presence in a directory does not prove network reachability.
7. You will be able to read the Confirmation of Payee reason codes and say which ones signal the shape of invoice redirection fraud.
8. You will be able to explain why allocation of a sorting code is not reachability, and why the EISCD needs refreshing weekly rather than inferring institutions from digit ranges.
9. You will be able to say why a collection account moves the real address into an eighteen-character reference field with no check digits and no validation.
10. You will be able to explain why over 99 per cent of Faster Payments initiators now check names and APP losses still rose 19 per cent in 2025.

A payroll clerk at a scaffolding firm in Wolverhampton opens an email from a supplier she has paid twenty-two times. The invoice is for £61,400. The reference is the one she expects, the letterhead is right, the VAT number is right, and the message arrives inside the same thread as the last four invoices. Exactly one thing has changed. At the bottom of the page the bank details are different, with a short apologetic note: new banking provider, please update your records before you run Friday’s payment.

She updates the records. The payment goes out on Friday. It arrives, in seconds, at an account that exists, at a bank that is regulated, in the name of somebody who is not the supplier. Nothing failed. Every system in the chain did exactly what it was built to do, which was to take an address and deliver to it.

This chapter is about that address: what it is made of, what the numbers inside it prove, what they cannot prove, and what was bolted on top of the whole arrangement in 2020 to try to catch precisely the Friday afternoon described above. All limits, timings, figures and version numbers here are accurate at the time of writing, August 2026, and payments infrastructure changes.

The plain version#

Think about how a letter gets to a house.

You write two different kinds of thing on an envelope. You write a name, and you write an address. Only one of them is used. The postal system reads the postcode and the house number, sorts the letter through a series of increasingly local buildings, and pushes it through a letterbox. Nobody at any stage compares the name on the envelope with the name of the person who lives there. If you put the right name and the wrong house number, the letter goes to the wrong house. If you put the wrong name and the right house number, the letter goes to the right house.

Bank payments were built the same way, and for the same reason: it is far faster to sort by number than to check by name.

The two numbers#

In Britain the address has two parts.

The first is the sort code: six digits, usually printed in three pairs, like 20-00-00. Think of it as the postcode. It says which organisation, and historically which branch of that organisation, the money is going to.

The second is the account number: eight digits, like 55779911. Think of it as the house number on that street. It says which specific customer, inside that organisation, gets the money.

Together they are fourteen digits, and those fourteen digits are the entire address. There is no third element. When you pay a plumber £2,400 from your phone, you type a name into a box, but the name is a label for your own records. The money is moved by the fourteen digits and nothing else.

The trick hidden inside the numbers#

Now, fourteen digits is a lot of digits to type, and people mistype. If one digit in a postcode is wrong, the letter usually bounces, because most wrong postcodes do not exist. But almost every combination of fourteen digits looks like a plausible bank address. So the banks did something clever: they built a hidden test into the account number itself.

Here is the idea in miniature. Suppose account numbers were only four digits long, and suppose the rule was this: multiply the first digit by 4, the second by 3, the third by 2 and the fourth by 1, add up the answers, and the total must divide exactly by 11.

Take the number 1325.

Four plus nine plus four plus five is 22. Twenty-two divided by eleven is exactly two, with nothing left over. So 1325 passes.

Now mistype it. Swap two digits, so you type 1352: 4 plus 9 plus 10 plus 2 is 25, which does not divide by 11. Rejected. Change one digit, so you type 1825: 4 plus 24 plus 4 plus 5 is 37, which does not divide by 11. Rejected.

That is the whole idea, and the real system is the same idea made bigger. The real test uses all fourteen digits, sort code and account number together, and each bank has its own set of multipliers. It is called a modulus check, and it runs before the payment screen will even let you press Next. It catches the overwhelming majority of typing mistakes, which is exactly what it was designed for and exactly the limit of what it does.

Writing the address for abroad#

Every country invented its own address format, and they do not fit together. A German account is eighteen digits arranged differently; a French one has letters in it. So Europe agreed on a standard envelope you can put any country’s domestic address inside, called an IBAN, which stands for International Bank Account Number.

A British IBAN looks like this:

GB29 NWBK 6016 1331 9268 19

Take it apart and there are no surprises in it:

So a British IBAN is a British bank address with a country label and a checksum stapled to the front. There is nothing new inside it.

The two check digits are the interesting part, because they protect the whole string rather than just the account number. The recipe is odd but it works. First, move the four characters at the front to the back. Then turn every letter into a number, where A is 10, B is 11, and so on up to Z as 35. You now have one very long number. Divide it by 97. If the IBAN was typed correctly, the remainder is exactly 1. Every time. For any country.

Working it the other way produces the check digits in the first place. Start with the account details and two zeros where the check digits will go, convert to a number the same way, divide by 97, and you get a remainder of 69. Subtract that from 98 and you get 29. That is where the 29 in GB29 comes from. It is not a reference number, it is not chosen by the bank, and it is not a secret. It is arithmetic.

There is one more code you will see on international paperwork, the BIC or SWIFT code, which looks like NWBKGB2L. It names the bank, not the account: four letters for the institution, two for the country, two for the town. It is the equivalent of writing “Barclays, Leeds” on an envelope. Useful, but on its own it will not get money to a person.

The name on the envelope, finally#

Return to the scaffolding firm in Wolverhampton. Every system did its job. The digits were valid, the sort code existed, the account existed, and the money arrived. What nobody did was look at the name.

In 2020, British banks started doing exactly that. The service is called Confirmation of Payee. When you type in a new payee, your bank sends the sort code, the account number and the name you typed to the bank at the other end, and asks a single question: is this the name on that account? The other bank answers in about a second, and you get one of four answers on your screen before you have sent anything.

Yes. The name matches. Carry on.

Close. It is nearly right, and here is the actual name on the account: you typed “Dan Okafor” and the account says “Daniel Okafor”. Check it and decide.

No. The name is wrong. You are shown no name at all, only a warning, because telling you the real name would let anyone with a keyboard harvest account holders’ names.

Cannot check. The other bank did not answer in time, or the account holder has opted out, or that kind of account is not covered.

The scale of the thing it is fighting is not small. In 2025, people and businesses in the United Kingdom lost £576.4 million to payments they authorised themselves after being deceived, which was 19 per cent more than the year before, and about a third of all payment fraud losses. Banks reimbursed £354.3 million of it, roughly 61 per cent. That is the number Confirmation of Payee exists to bring down: not money stolen from accounts, but money pushed out of them by the account holder, into an address that was perfectly valid and completely wrong.

Where the plain version stops being true#

The envelope is a good picture of routing and a poor picture of nearly everything else. Four corrections.

The first correction is that the address is not a place, is not permanent, and is very often not unique to one person. A house stands still. A sort code and account number pair is a row in a directory, and directories are edited constantly. Sort codes move between institutions when a bank is bought or a brand retired. Crucially, a sort code does not reliably tell you which bank holds the money: under indirect access, a sponsoring bank allocates sort codes from its own range to smaller firms that settle through it, so the institution named against the sort code and the institution where your payee actually banks can be two different companies. Meanwhile, the Current Account Switch Service moves customers between banks and redirects payments arriving at the old address to the new one, silently, for years. And a very large number of real-world accounts are collection accounts: one sort code and account number belonging to a platform, a broker or a savings marketplace, into which tens of thousands of customers pay, with the individual identified only by the payment reference. In that arrangement the fourteen digits are the building and the reference field is the flat number, and the reference field has no check digits, no validation and no protection whatsoever.

The second correction is that every check described above tests the number against itself, and none of them tests the number against reality. This is the single most expensive misunderstanding in the field. A modulus check answers one question: could this pattern of digits be a legitimate combination for this sort code? It does not say the account exists, is open, has ever been issued, or belongs to anyone. Worse, passing is weak evidence by construction. A modulus 10 check accepts roughly one in ten random numbers by chance; a modulus 11 check roughly one in eleven. Failing is strong evidence; passing is barely evidence at all. The IBAN check digits are weaker still in this respect: they verify that a string was transcribed correctly, and say nothing about whether the account exists or whether the bank code and sort code inside it even agree. And for some sort codes there is no arithmetic at all. The published rules are explicit that when a sort code falls outside every range in the weight table, no modulus check can be performed and the details should be presumed valid unless other evidence suggests otherwise. Presumed valid. That is the honest position of the whole domestic validation layer, and it sits a long way from the confidence implied by a green tick.

The third correction is that Confirmation of Payee is advisory, partial and deliberately fuzzy, and is none of the three things people assume. It is not a block: the payer sees the result and can carry on regardless, and in a competently run scam the payer has already been told to expect a mismatch and given a reason for it. It is not comprehensive: the responding bank can decline to answer, the account holder can opt out, certain account types are not supported, and payments where either party is outside the United Kingdom are outside the requirement entirely. And it is not exact. Name matching is intentionally tolerant, because real account names contain initials, married names, trading names, punctuation and the ordinary noise of human typing, and a literal comparison would reject correct payments all day. The “close match” answer exists because rejecting every payment to “J Smith” when the account says “John Smith” would have made the service unusable. Somebody at each responding institution tuned that tolerance, and the tuning is not published. Most fundamentally, the service checks whether a name matches an account. It cannot check whether the person behind that account is who they claim to be, or whether the goods will ever arrive. Against purchase scams, where the payee’s real name really is on the account, it does almost nothing.

The fourth correction is that there is no single worldwide address format, the IBAN is not it, and Britain does not use IBANs domestically anyway. IBAN covers Europe and a long tail of adopters elsewhere; the United States, Canada, India, China, Japan and Australia do not use it. A domestic Faster Payment, a domestic CHAPS payment and a Bacs Direct Debit are every one of them addressed with a bare sort code and account number, and a British consumer can bank for forty years without seeing an IBAN. Nor is the BIC an address in the same sense: it identifies an institution, or a branch or department within one, and never an account. An IBAN without a BIC is usually a complete destination. A BIC without an account identifier is a building with no room number.

The technical version#

The domestic identifier pair#

The addressing primitive for all three principal sterling interbank rails — Bacs, Faster Payments and CHAPS — is a six-digit sorting code paired with an account number. Nothing in the domestic schemes routes on name, and nothing routes on IBAN.

Sorting codes are allocated by Pay.UK on behalf of the industry. Direct participants receive codes through the onboarding process for the payment system concerned; indirect participants receive codes sub-allocated by their sponsoring direct participant, and settle through that sponsor’s agency arrangement. Pay.UK also allocates sorting codes to firms that issue GB IBANs for international payments even where those firms do not participate in a UK payment system at all. The operational rules are overseen by the Clearing Codes Operational Group, whose membership includes direct participants, Pay.UK and Vocalink.

The governing rule for practitioners is that allocation is not reachability. A sorting code must be separately registered with each payment system before it can be used in that system. A code registered for Bacs Direct Credit is not thereby usable for Direct Debit; a code registered for Faster Payments is not thereby usable for CHAPS. Systems that validate a sorting code’s existence but not its scheme registration produce a characteristic class of rejection that looks like a data error and is in fact a reachability error.

The Extended Industry Sort Code Directory#

The public extract of the central sorting code database is the Extended Industry Sort Code Directory (EISCD), successor to the Industry Sort Code Directory, published under Pay.UK’s governance and distributed by Vocalink. It is the authority, and no heuristic about digit ranges should ever be used in its place.

For each sorting code the EISCD carries, among other fields, the branch title, the postal address and telephone number, the associated BIC, and clearing participation records showing which schemes that code is registered for and which settlement member it clears through. Subscription is on a quarterly fee basis with unlimited downloads; the guidance is that monthly refresh is the minimum and weekly is advisable, and many originators take it through their Bacs software rather than directly. For a Bacs originator or approved supplier this file is not optional infrastructure. It is the difference between rejecting a payment at capture and discovering the problem in an ARUCS or ARUDD report three working days later.

Historically the leading digits carry institutional meaning: blocks were assigned to the clearing banks when the six-digit format was introduced, and the legacy is visible in the ranges the large groups still occupy. It is a legacy and not a rule. New entrants have been allocated ranges with no historical logic, groups have merged and codes have transferred. Any code that infers the institution from the first two digits will eventually be wrong, silently, in production.

Account number normalisation#

The account number is nominally eight digits, and institutions have never been uniform about it. Before any validation is attempted, the account number must be normalised to eight digits according to the published rules. Shorter numbers are zero-prefixed. Several institutions issue nine- or ten-digit numbers and specify which eight digits are significant, and in one case specify that a digit of the account number displaces a digit of the sorting code before checking. Building societies add a further layer: many hold balances against a roll number rather than an account number, with payments routed to a single society account and allocated internally from the reference field. Roll numbers have institution-specific formats, cannot be modulus checked, and are the reason the Confirmation of Payee schema carries a secondary identification field at all.

Modulus checking#

Modulus checking is the domestic self-consistency test on the fourteen-digit pair. The specification is published by Vocalink as Validating Account Numbers: UK Modulus Checking; at the time of writing the current release is version 8.70, dated 10 February 2026. Two reference files accompany it: valacdos.txt, the weighting table, and scsubtab.txt, the sorting code substitution table used by certain exceptions.

Positions are named by letter throughout the specification. The six sorting code digits are u v w x y z; the eight account number digits are a b c d e f g h. Every rule is expressed against those fourteen positions.

Rows in valacdos.txt are fixed-length, space-separated, and consist of a sorting code range start, a range end, a modulus check type, fourteen weights for u through h, and an optional exception number. A row therefore looks like this in shape:

010004 016715 MOD11 0 0 0 0 0 0 8 7 6 5 4 3 2 1

A sorting code may appear in two rows. That means two checks are specified, and both are ordinarily required to pass, except where a numbered exception states that either check passing is sufficient.

Three algorithms are defined.

The digit-summing step in DBLAL is where most reimplementations go wrong, and it is worth doing once by hand.

Worked MOD11. Sorting code 000000, account number 58177632, weights 0 0 0 0 0 0 7 5 8 3 4 6 2 1.

The sum is 176. 176 divided by 11 is 16 with no remainder. The check passes.

Worked DBLAL. Sorting code 499273, account number 12345678, weights 2 1 2 1 2 1 2 1 2 1 2 1 2 1.

The sum of the bottom row is 70. 70 divided by 10 is 7 with no remainder. The check passes. Note that summing the products instead would give 106, and 106 fails. The two routes disagree, and only one of them is the specification.

Fourteen numbered exceptions modify the standard procedure. They exist because individual institutions carried their own pre-existing check schemes into the industry standard and were not going to renumber their customers. Summarised, and always to be implemented from the current specification rather than from any summary:

Exception 14 is worth working through because it shows how much of the specification is history rather than mathematics. Sorting code 180002, weights 0 0 0 0 0 0 8 7 6 5 4 3 2 1.

Account 98093517 gives products 72, 56, 0, 45, 12, 15, 2 and 7 across positions a to h, summing to 209. 209 divided by 11 is 19 exactly. It passes on the first check and exception 14 is never invoked.

Account 00000190 sums to 21. 21 divided by 11 leaves a remainder of 10, so the first check fails. Because h is 0, exception 14 applies: drop the trailing digit and prefix a zero to make 00000019. That sums to 11, which divides by 11 exactly. The account passes.

Two properties of modulus checking must be stated plainly to anyone building on it. First, the specification itself directs that where a sorting code is not found in the weighting table, no check can be performed and the details should be presumed valid. Second, a passing check carries very little information. A MOD10 rule admits about one in ten arbitrary numbers and a MOD11 rule about one in eleven. Modulus checking is a typo filter of very high value at the point of capture and a fraud control of no value whatsoever.

The IBAN#

The IBAN is specified by ISO 13616, with Swift acting as the registration authority and publishing the IBAN Registry that lists each participating country’s format.

The United Kingdom’s entry is:

Read in the registry’s notation, 2!n means exactly two numeric characters, 4!a exactly four alphabetic, and ! denotes a fixed rather than maximum length. So a GB IBAN is: the literal country code GB, two check digits, a four-letter bank identifier which is conventionally the first four characters of the institution’s BIC, the six-digit sorting code as the branch identifier, and the eight-digit account number. The sorting code and account number are carried unaltered. A GB IBAN contains no information a domestic payment instruction does not already have.

Other formats vary in length and content, which is why length-based validation alone is insufficient:

The check digits are computed under ISO/IEC 7064, MOD 97-10. The generation procedure is:

1. Assemble the BBAN, then append the country code and the two literal characters 00.
2. Replace each letter with two digits: A is 10, B is 11, through to Z as 35.
3. Interpret the result as a single integer and take it modulo 97.
4. Subtract the remainder from 98. If the answer is a single digit, pad it to two digits with a leading zero.

Worked through for the registry example. The BBAN is NWBK60161331926819. Appending GB00 gives NWBK60161331926819GB00. Converting the letters — N is 23, W is 32, B is 11, K is 20, G is 16, B is 11 — produces:

2332112060161331926819161100

That integer modulo 97 is 69. 98 minus 69 is 29, giving the check digits 29 and the complete IBAN GB29NWBK60161331926819.

Validation is the same arithmetic run the other way. Move the first four characters to the end, convert letters to digits, and take the result modulo 97. A correctly formed IBAN always yields exactly 1. For the example, rearranging gives NWBK60161331926819GB29, which converts to 2332112060161331926819161129, and that modulo 97 is 1.

That integer is twenty-eight digits long and will overflow a 64-bit type, so implementations that do not use arbitrary-precision arithmetic must compute the modulus piecewise. The standard technique takes the first nine digits, reduces modulo 97, then repeatedly prefixes the running remainder to the next seven digits and reduces again. For the string above:

Which is the 69 the generation step needs. Nine and seven are chosen because the largest intermediate value stays inside the range of a 32-bit signed integer.

MOD 97-10 detects all single-character substitutions and all transpositions of adjacent characters, which is the entire design goal. It detects nothing about the account behind the string.

The BIC#

The BIC is specified by ISO 9362, with Swift as registration authority. Since the 2022 revision the expansion is Business Identifier Code rather than Bank Identifier Code, reflecting that non-bank entities hold them.

The structure is four characters of business party prefix, two characters of ISO 3166-1 country code, and two characters of business party suffix, giving the eight-character BIC8. An optional three-character branch identifier extends this to the eleven-character BIC11, used to identify a specific location, department, service or unit of the same business party. By convention XXX in the branch position denotes the head office, and a BIC8 and the corresponding BIC11 ending XXX address the same party.

Swift distinguishes connected BICs, which have access to the Swift network, from non-connected BICs, registered for reference purposes only and with no right or authorisation to exchange messages over it. A BIC present in a directory is therefore not proof of reachability, any more than an EISCD sorting code is proof of scheme registration. The second character of the business party suffix carries a convention of its own, and Swift has published enough about it to settle the point. Swift’s information paper on the ISO 9362 implementation states that addresses ending in a zero in position eight are used only for the Test and Training service, that they are not published in the directory of BICs, and that this convention will not change. A one in the same position historically meant the BIC was not connected, and Swift’s published BIC Policy still illustrates a non-connected BIC as an eight-character BIC with a one in the eighth position. The connectivity reading, however, is no longer safe to compute. Since November 2018 an organisation connecting or disconnecting no longer needs a new BIC, and Swift’s own guidance is that users should rely on the network connectivity status attribute in the SWIFTRef directories rather than on the intelligence once carried in position eight.

The essential point is categorical: the BIC identifies an institution or a unit within one, never an account. In cross-border messaging it names the parties and the route; the account is named by the IBAN or by a domestic identifier carried alongside.

Confirmation of Payee#

Confirmation of Payee is an account name-checking overlay operated under Pay.UK’s standards, launched in 2020. It is not a payment system and it moves no money. Architecturally it is a peer-to-peer API service: there is no central switch, only a directory identifying the organisations in the ecosystem, and requests pass directly between the requesting PSP and the responding PSP. Account-holding PSPs may build directly or use a technical service provider; smaller PSPs may reach the service through a CoP aggregator, of which Pay.UK lists nine approved.

The service is payment-system agnostic: Pay.UK describes it as applicable to domestic UK payments across CHAPS, Faster Payments and Bacs, covering both credit and debit flows, and a companion capability, Payer Name Verification, extends name checking to the setting up of Bacs Direct Debits.

A request carries a small, fixed set of fields:

The matching is performed by the responding PSP against its own records; the requester never receives the account name on a negative result. The response carries a boolean match indicator and, where the match is not a straight yes, a reason code. The codes in use are:

The account type distinction and the four codes covering it are frequently overlooked in implementation and are among the most operationally useful signals the service produces. A payment addressed to a business but landing on a personal account is a common shape for invoice redirection fraud.

Phase 1, Phase 2 and the regulatory timetable#

Phase 1 went live in 2020 and covered the six largest banking groups, which between them accounted for around 90 per cent of Faster Payments and CHAPS transactions. It required full Open Banking membership to participate and, structurally, only supported PSPs holding their own unique sorting codes and identifying customers by sorting code and account number alone. That left two gaps: firms without their own sorting code, and accounts identified by something else, such as building society roll numbers or credit card numbers.

Phase 2 addressed both. A dedicated CoP-only role profile was created in the Open Banking Directory so that a PSP could enrol for name checking without taking on the full Open Banking estate, and the standard was extended to carry secondary reference data (SRD) so that roll numbers and card numbers could identify the target account. Pay.UK’s guidance gives the two canonical SRD cases as a sixteen-digit card number when paying a credit card bill and a roll number for some building society accounts.

The regulatory backing sits with the Payment Systems Regulator. Specific Direction 10 mandated Phase 1 for the six largest groups. Specific Direction 17, issued in October 2022, expanded the mandate in two tranches: Group 1 PSPs, named in the direction, by 31 October 2023, and Group 2 PSPs by 31 October 2024. Group 2 is defined by having a unique sorting code, or being a building society, and sending funds for customers over CHAPS or the Faster Payment Service into accounts consumers and businesses can pay into and be paid from. Directed firms must implement both the sending and the responding sides unless they hold only account types where responding alone is appropriate.

The exclusions matter as much as the scope. The direction does not apply where either party is outside the United Kingdom, to loan repayments including mortgages, credit cards and buy-now-pay-later, to a PSP moving its own money, or to bulk and batch payments submitted by indirect PSPs.

On coverage, the PSR’s compliance report of 18 November 2025 recorded that over 99 per cent of organisations initiating Faster Payments transactions in the United Kingdom offer CoP checks, that over 320 organisations offer the service, and that over two million checks are completed each day.

Where the address sits on each rail#

Addressing is the same fourteen digits everywhere, but the container differs.

Bacs carries payment instructions in the Standard 18 format: fixed-position records of 100 characters, with an optional extension for multi-processing files. The destination sorting code occupies positions 1 to 6 and the destination account number positions 7 to 14, so the fourteen-digit address is literally the first fourteen characters of the record. Position 15 is the destination account type, positions 16 to 17 the transaction code, positions 18 to 23 and 24 to 31 the originating sorting code and account number, positions 32 to 35 a four-character free format field, positions 36 to 46 the amount in pence, positions 47 to 64 the originator’s name in eighteen characters, and positions 65 to 82 the eighteen-character payment reference. Multi-processing files carry a processing date at positions 101 to 106 in the format bYYDDD.

The eighteen-character reference is the pinch point. In a collection-account architecture the reference is the real address, and eighteen characters with no validation is all the protection it has. Pay.UK also publishes an ISO 20022 to Standard 18 translation guide for originators moving between the two.

CHAPS has carried ISO 20022 messages since 19 June 2023, with customer credit transfers as pacs.008. The Bank of England has been progressively mandating enhanced data within those messages. From 1 May 2025, Legal Entity Identifiers became mandatory for payments between financial institutions, and Purpose Codes became mandatory both for payments between financial institutions and for property transactions, using six specified codes: HLRP, HLST, PLDS, PDEP, PCOM and PLRF. Hybrid addresses — town name, country and up to two unstructured lines — were enabled from November 2025, and fully unstructured addresses are to be rejected by the CHAPS validation library from November 2026. The Bank has consulted on extending mandatory enhanced data to all initiation channels and Purpose Codes to all CHAPS payments from November 2027. The direction of travel is unambiguous: the address is being made structured and machine-readable, party by party and field by field.

Faster Payments carries the same sorting code and account number in scheme messages, with Pay.UK publishing an ISO 20022 standards library as part of the migration away from the legacy message format. The relevant scheme constraint for addressing purposes is the £1 million maximum per transaction; individual PSPs set their own lower limits by channel, account type and payment type, and those limits, not the scheme limit, are what a customer meets in practice.

Open Banking payment initiation is an API layer over these rails, chiefly Faster Payments. It changes who constructs the instruction, not how the destination is addressed.

APP fraud and the reimbursement regime#

Confirmation of Payee was introduced because addressing by number alone left one specific hole, and the hole has a name: authorised push payment fraud, in which the customer is deceived into instructing a payment to an account the fraudster controls. Every technical control described in this chapter is satisfied in an APP scam. The modulus check passes. The IBAN, if there is one, validates. The sorting code is registered. The account exists.

The regulatory response went beyond name checking. Since 7 October 2024, the PSR’s reimbursement requirement has applied to in-scope APP scam payments made over Faster Payments and CHAPS. The consolidated policy sets a maximum of £85,000 per claim, permits a claim excess of up to £100 which a PSP may set lower or not apply at all, and requires reimbursement within five business days, with defined circumstances in which the clock may be stopped and an absolute backstop of the thirty-fifth business day following the report. The cost is split evenly: receiving PSPs must pay sending PSPs 50 per cent of the reimbursement made to the consumer. A consumer standard of caution exception allows a claim to be refused for gross negligence against four defined requirements, including responding to interventions, reporting within thirteen months, sharing information and reporting to the police. Neither the standard of caution exception nor the excess may be applied to vulnerable consumers.

The scale, from UK Finance’s 2026 Annual Fraud Report covering 2025: total payment fraud losses of £1.28 billion across more than four million cases, of which APP fraud accounted for £576.4 million, up 19 per cent year on year and 32 per cent of all losses. Investment fraud within that rose 40 per cent to £221.5 million. Around two-thirds of APP fraud originated online and 17 per cent through telecommunications. Firms reimbursed £354.3 million, some 61 per cent of APP losses.

Those two facts sit together and explain the shape of the whole control stack. Coverage of name checking is above 99 per cent of Faster Payments initiators, and APP losses still rose 19 per cent. Confirmation of Payee closed the misdirection problem. It did not close the deception problem, because it was never capable of doing so.

The summary a practitioner should carry#

A UK domestic payment is addressed by six digits of sorting code and eight digits of account number, and by nothing else. The sorting code is allocated by Pay.UK, sub-allocated by sponsors for indirect participants, and must be separately registered with each payment system it is to be used in; the EISCD is the authority for both ownership and scheme registration, and it should be refreshed weekly. Account numbers must be normalised to eight digits before validation.

Modulus checking, specified by Vocalink and driven by valacdos.txt and scsubtab.txt, runs one or two of MOD10, MOD11 or DBLAL against the fourteen positions u to h, subject to fourteen numbered exceptions. It is a high-value typo filter, it admits roughly one in ten or one in eleven arbitrary numbers by chance, and where a sorting code is absent from the table the specification directs that the details be presumed valid.

The IBAN under ISO 13616 wraps the same domestic pair in a country code and two MOD 97-10 check digits computed under ISO/IEC 7064; validation is the rearranged string modulo 97 equalling 1, and the check protects transcription and nothing else. The BIC under ISO 9362 names an institution or a unit within one, never an account, and its presence in a directory does not imply network connectivity.

Confirmation of Payee is a peer-to-peer API overlay, mandated in tranches under PSR Specific Direction 17 to 31 October 2023 and 31 October 2024, covering Faster Payments and CHAPS and excluding international payments, loan repayments, a PSP’s own funds and indirect bulk submissions. It returns a match indicator and a reason code, performs matching at the responding PSP, and never reveals a name on a mismatch. It catches the wrong address. It cannot catch the wrong intention, which is why the reimbursement regime of 7 October 2024 exists alongside it and why, in a system where over 99 per cent of Faster Payments initiators check names, £576.4 million still went to the wrong people in 2025.

The scaffolding firm’s payroll clerk had every number right. That was always the problem.

39.98 Common wrong ideas#

Wrong: The payee name is part of the address and is checked before delivery. Right: A UK domestic payment is routed by six digits of sorting code and eight of account number and by nothing else; the name is a label for the payer’s own records.

Wrong: A passing modulus check means the account exists. Right: It tests the fourteen digits against themselves only, and a MOD10 rule admits about one in ten arbitrary numbers while a MOD11 rule admits about one in eleven; failing is strong evidence, passing is barely evidence at all.

Wrong: Every sorting code can be modulus checked. Right: Where a sorting code falls outside every range in the weighting table no check can be performed, and the published specification directs that the details be presumed valid.

Wrong: A sorting code identifies the institution holding the money, and once allocated it can be paid on any rail. Right: Sponsors sub-allocate codes from their own range to indirect participants, so the named institution and the payee’s actual bank can differ, and a code must be separately registered with each payment system before it is usable there.

Wrong: The IBAN check digits prove the account is real. Right: MOD 97-10 detects all single-character substitutions and all adjacent transpositions and nothing else, saying nothing about whether the account exists or whether the bank code and sorting code inside the string even agree.

Wrong: A BIC identifies an account and proves you can send to it. Right: The BIC names an institution or a unit within one, never an account, and non-connected BICs are registered for reference only with no right to exchange messages over the network.

Wrong: British payments are addressed by IBAN. Right: Domestic Faster Payments, CHAPS and Bacs Direct Debits all carry a bare sorting code and account number, and a British consumer can bank for forty years without seeing an IBAN.

Wrong: Confirmation of Payee blocks a payment when the name does not match. Right: It is advisory; the payer sees the result and may carry on, and in a competently run scam the payer has already been told to expect a mismatch and given a reason for it.

Wrong: Confirmation of Payee covers every payment. Right: The direction excludes payments where either party is outside the United Kingdom, loan repayments, a PSP moving its own money and indirect bulk submissions, and the payee can opt out.

Wrong: Name matching is an exact comparison. Right: It is deliberately tolerant, which is why the close-match answer exists, because rejecting every payment to “J Smith” against an account reading “John Smith” would make the service unusable; each responder tunes that tolerance and the tuning is not published.

39.99 Chapter summary in 20 lines#

1. A UK domestic payment is addressed by a six-digit sorting code and an eight-digit account number, and by nothing else.
2. The name typed into the payee box is a label for the payer’s records, because no domestic sterling rail routes on name.
3. Modulus checking is a self-consistency test built into those fourteen digits, specified by Vocalink and driven by the weighting table valacdos.txt and the substitution table scsubtab.txt.
4. Three algorithms are defined, MOD10, MOD11 and DBLAL, and DBLAL’s step of summing the digits of each product rather than the products themselves is where reimplementations go wrong.
5. Fourteen numbered exceptions modify the standard procedure, because institutions carried their own pre-existing check schemes into the industry standard rather than renumber their customers.
6. A passing check carries very little information, and where the sorting code is absent from the weighting table the specification directs that the details be presumed valid.
7. Modulus checking is therefore a typo filter of very high value at the point of capture and a fraud control of no value whatsoever.
8. Sorting codes are allocated by Pay.UK, sub-allocated by sponsors to indirect participants, and must be separately registered with each payment system, so allocation is not reachability.
9. The Extended Industry Sort Code Directory is the authority for both ownership and scheme registration, and should be refreshed weekly rather than guessed at from leading digits.
10. Account numbers must be normalised to eight digits before validation, and building society roll numbers cannot be modulus checked at all.
11. Very many real accounts are collection accounts, where the fourteen digits are the building and an unvalidated eighteen-character reference is the flat number.
12. The IBAN under ISO 13616 wraps the same domestic pair in a country code and two check digits, adding no information a domestic instruction does not already carry.
13. Those check digits are computed under ISO/IEC 7064 MOD 97-10, and validation rearranges the string, converts letters to digits and takes the remainder modulo 97, which is always exactly 1.
14. The resulting integer overflows a 64-bit type, so implementations without arbitrary-precision arithmetic must reduce it piecewise, nine digits and then seven at a time.
15. MOD 97-10 protects transcription and detects nothing about the account behind the string.
16. The BIC under ISO 9362 names an institution or a unit within one, never an account, and directory presence does not imply network connectivity.
17. Confirmation of Payee, launched in 2020, is a peer-to-peer API overlay with no central switch, matching at the responding PSP and never revealing a name on a mismatch.
18. Its reason codes carry more than a yes or no, and the four account-type codes flag a business payment landing on a personal account, a common shape for invoice redirection fraud.
19. Specific Direction 17 mandated the service in tranches to 31 October 2023 and 31 October 2024, excluding international payments, loan repayments, a PSP’s own funds and indirect bulk submissions.
20. Over 99 per cent of Faster Payments initiators now check names and APP losses still rose 19 per cent to £576.4 million in 2025, because the address was never the thing that was wrong.

Sources: Pay.UK, including the Confirmation of Payee service pages and FAQs, the Extended Industry Sort Code Directory pages, sort code information and allocation guidance, Faster Payment System transaction limits, and the ISO 20022 to Standard 18 translation guide; Vocalink, Validating Account Numbers: UK Modulus Checking, version 8.70 dated 10 February 2026; Swift, the IBAN Registry as ISO 13616 registration authority, and the BIC pages for ISO 9362; Payment Systems Regulator, Specific Direction 17 and the associated requirements pages, CP21/6 on Confirmation of Payee Phase 2, the Confirmation of Payee compliance report of 18 November 2025, and PS25/5, the consolidated policy statement on the APP scams reimbursement requirement; Bank of England, policy statement on mandating ISO 20022 enhanced data in CHAPS; UK Finance, Annual Fraud Report 2026 covering 2025; Bacs Standard 18 message implementation guidance.