Who maintains the codes on an international transfer

An international payment instruction carries several codes, and they do not come from one place. They sit in separate registers, kept by different bodies under different rules about who may add to them - which is why a payment into Australia is addressed differently from one into Germany. This guide is about that register system rather than the route the money takes; for the route, see how international money transfers work.

Key Takeaways

• Swift is ISO's registration authority for both standards, but it issues BICs and only publishes IBAN formats.
• Only a national standards body or central bank can register its country's IBAN format, and eighty-nine are registered.
• Australia is not among them, nor are New Zealand, the United States, Canada, India, China, Japan or Singapore.
• An IBAN wraps a country's existing account numbering rather than replacing it.
• These codes answer "does this exist". None answers "is this the person you meant".

Three registers, three keepers

The codes name different things, and that is the first thing to separate.

A BIC names a business party, not an account. Swift issues them as ISO registration authority, in two kinds: connected codes, held by institutions that exchange messages over the Swift network, and non-connected codes, which are reference data and carry no right to connect at all. Each record holds a legal name, a registered address, whether the holder is a financial institution, and the dates it was published, updated and expires. The applicant, not Swift, is responsible for that data being right, and holders must reconfirm it or report a change at least once a year.

An IBAN names one account, in a format belonging to a country rather than to a bank. Swift publishes the register of those formats and updates it on request, but does not decide what goes in.

A BSB names a routing point inside the Australian clearing system, and AusPayNet issues one to each member of it. A Tier 1 member settles directly across a Reserve Bank Exchange Settlement Account; a Tier 2 member appoints a Tier 1 member to settle for it; an organisation that is neither reaches the system through a member rather than holding a code at all. AusPayNet publishes the full directory and a monthly change file, refreshed on the first New South Wales business day of each month.

Their internal structure is a separate subject, covered on the SWIFT code, IBAN and BSB pages.

Only a country can put its own format on the list

ISO designated Swift the registration authority for national IBAN formats, and the eligibility rule is narrow: only a national standards body or a national central bank may request a registration for its country. Not a bank, not a payments company.

The register records who asked. The United Kingdom's entry names Payments UK Management Ltd and took effect in April 2007; Germany's names the Bundesverband deutscher Banken and took effect that July.

What gets registered is a description of the account numbering a country already has, not a new scheme. The British entry sets out a four-letter bank identifier, a six-digit branch identifier and an eight-digit account number: the sort code and account number a customer already held, with a country code and check digits placed in front. The German entry describes an eight-digit bank identifier and leaves the branch field empty, because German numbering has no branch element to describe.

So an IBAN is a wrapper, which makes registering one an administrative decision rather than a technical upgrade.

Why Australia is not on it

Eighty-nine country formats are registered, some covering further territories: the French entry extends to a dozen overseas departments and collectivities, the British one to the Isle of Man, Jersey and Guernsey. Australia is not among the eighty-nine, and neither is New Zealand, the United States, Canada, India, China, Japan or Singapore.

Nothing about the Australian arrangement is incompatible with the standard. A BSB is a branch identifier and an account number is an account identifier, precisely the shape the register describes for everyone else. Registration is voluntary, it has to be asked for by the country's own institutions, and no Australian body has asked.

For an inbound sender that means no single string to hand over: the bank's BIC, the BSB and the account number arrive as three separate items rather than one.

It shows up inside the message too. The ISO 20022 element that identifies an account is an either/or: an IBAN, or Other, an identifier carried together with the name of the scheme it belongs to. Countries with a registered format use the first branch. Australian account details travel in the second.

What the codes are checked against, and what they are not

Each code is verified against something different, and none of them against the account holder.

A BIC contains no arithmetic: it is correct because it appears in the register Swift maintains, so the register is the check. An IBAN carries its own check digits, making a mistyped character detectable without asking anyone - the IBAN page works that test through. A BSB is correct because it appears in the file AusPayNet publishes each month.

All three answer the same narrow question: does this string exist, and has it been transcribed correctly. None answers whether there is an open account behind it, or whether that account belongs to the person the sender meant. Australia's ePayments Code makes the gap explicit rather than papering over it, requiring a subscribing institution's internet banking service to warn the user on screen, before the payment is confirmed, that if the institution does not match account names and identifiers then "the names and identifiers will not be matched, verified or checked".

Closing that gap has to be built separately, and jurisdictions have taken different routes to it. Australia's is industry-run: Australian Payments Plus began rolling out Confirmation of Payee across the banks from 2025, as a check offered before a payment is authorised rather than an obligation imposed by statute. In the European Union it became a legal duty: under Regulation (EU) 2024/886 a payer's provider must offer a service matching the payee's name against the account identifier and, where the two do not correspond, tell the payer that authorising the transfer might send the funds to an account not held by the payee named. Providers in euro-area member states had to comply from 9 October 2025; those outside the euro have until 9 July 2027.

What happens when one of them is wrong

The Australian answer is the ePayments Code, which ASIC administers. It defines a mistaken internet payment as one where funds reach an unintended recipient because the user entered or selected a BSB number or identifier that does not belong to the intended recipient, through their own error or through being given the wrong details. The Code's own note draws the boundary: it is aimed at typographical errors and at picking the wrong entry from a list, and a payment made because of a scam is not a mistaken internet payment.

Where the funds are still in the unintended recipient's account, three windows follow, set by how quickly the payment was reported:

Where the money has already gone, the receiving institution weighs the sender's position against the recipient's, and may pursue all of it, part, or none.

The message the codes travel in changed

The identifiers outlived the message format built around them. On 22 November 2025 the coexistence period between the older MT messages and ISO 20022 ended for cross-border payments and reporting, after a transition begun in March 2023, and ISO 20022 became the required format for payment instructions - with a conversion service left running for a period to carry remaining MT traffic across.

For the codes themselves nothing changed: a BIC is still a BIC. What changed is the container. Party and account details now sit in named, structured elements, including the either/or above - which is what puts an IBAN and an Australian BSB-and-account pair in visibly different fields of one message.

Where to look next

• How international money transfers work - the routes, the charges and the compliance checks.
• SWIFT code - what the characters of a BIC encode.
• IBAN - what an IBAN encodes, and why Australia issues none.
• BSB number - what an Australian payment instruction carries.
• Remittance - how the cost of sending money is measured.

Sources

• Swift, IBAN (International Bank Account Number) and BIC (Business Identifier Code) - ISO's designation of Swift as registration authority for both standards, the rule that only a national standards body or national central bank may request an IBAN format registration, the two kinds of BIC, the contents of a BIC data record, applicant responsibility for accuracy and the annual reconfirmation obligation
• Swift, ISO 13616 IBAN Registry (text format, read 3 September 2026) - the eighty-nine registered country formats and the absence of Australia, New Zealand, the United States, Canada, India, China, Japan and Singapore; the registrant organisation and effective date recorded per country; the United Kingdom and German structures; the territories covered by the French and British entries
• Australian Payments Network, Static Download Links for BSB Files and Navigating Payments for New Entrants - the BSB as an identifier issued by AusPayNet to clearing system members, Tier 1 and Tier 2 membership and settlement across Exchange Settlement Accounts, and the full directory plus monthly update file refreshed on the first New South Wales business day of each month
• ASIC, ePayments Code (June 2022) - clause 25.2's definition of a mistaken internet payment and its note excluding scams, clause 27.1's on-screen warning that names and identifiers will not be matched, verified or checked, and the recovery processes in clauses 30, 31, 32 and 34
• Regulation (EU) 2024/886 - Article 5c's matching service, the notification owed to the payer where the name and the account identifier do not correspond, and the 9 October 2025 and 9 July 2027 compliance dates
• ISO 20022, AccountIdentification4Choice - the account identification element as a choice between an IBAN and an "Other" identifier carried with its scheme
• Swift, ISO 20022: A new era for global payments (25 November 2025) - the end of MT and ISO 20022 coexistence for cross-border payments and reporting on 22 November 2025, the transition that began in March 2023, and the conversion service left in place

Not financial advice, and not a recommendation of any product or institution. Reviewed by the Tradergy editorial team, September 2026.