If you are searching for how to translate bank account details, how to translate IBAN and SWIFT/BIC information, or how to preserve routing numbers, beneficiary names and payment instructions across languages, the first principle is that banking identifiers are not ordinary prose. An IBAN, SWIFT/BIC code, routing number, branch code, account number or beneficiary reference is operational data. A translation that changes even one protected character can make a payment fail, route money to the wrong institution, trigger a compliance review or create an expensive reconciliation problem.
Banking translation therefore requires two different kinds of accuracy at the same time. The prose around the payment must be understandable in the target language, while the protected identifiers inside it must remain exact unless the issuing bank itself specifies a different official presentation. The translator must know which elements are translatable labels, which are account-holder names, which are standard banking codes, which are local clearing identifiers, and which are explanatory values such as currency, branch, payment purpose or beneficiary address.
This guide explains how to translate bank account numbers, IBANs, SWIFT/BIC codes, ABA routing numbers, sort codes, branch codes, beneficiary details and international payment instructions without changing payment identity. It also shows how to distinguish translation from transliteration, how to handle spaces and grouping safely, how to preserve currency and country information, and how to review a translated banking document so the target reader can use it without corrupting the underlying payment data.
Why payment identifiers must be treated differently from ordinary words
Ordinary text can often tolerate reformulation. “Please send the payment within five business days” can be expressed in several natural ways without changing the practical instruction. A banking identifier cannot. If an account number is 0123456789, a translator has no stylistic freedom to reorder, shorten, localise or “correct” the digits. If a SWIFT/BIC code is ABCDSGSGXXX, the letters are not a sentence to be translated; they are a standardised identifier that points to a financial institution and, in some cases, a branch.
This makes banking translation a mixed-data task. Some elements are linguistic: “beneficiary name,” “intermediary bank,” “payment reference,” “branch address,” “account currency,” “charges borne by sender.” Other elements are fixed identifiers: IBAN, BIC, account number, bank code, routing number, sort code and sometimes national tax or company identifiers used in payment workflows. The translator must separate these layers before drafting.
A second difficulty is that banking systems differ by country. The United States uses routing numbers in ways that do not map directly onto UK sort codes, Australian BSB numbers, Indian IFSC codes or Singapore bank/branch identifiers. A translator should not replace one country’s banking identifier with the name of another system simply to make the text sound familiar. Functional similarity does not create identity.
A reliable method for translating bank-payment information
1. Separate protected data from translatable labels
Before translating, mark every identifier that should remain exact: IBAN, SWIFT/BIC, local account number, routing code, branch code, sort code, IFSC, BSB, payment reference, invoice number and transaction ID. Then mark the labels around them. This simple separation prevents a translator or machine system from treating a code as ordinary text.
2. Confirm what each identifier actually is
Do not infer from shape alone. A short numeric string might be a branch code, account number, routing number or internal reference. Use headings, source-bank documentation or the document context to identify its function. Accurate labeling is part of translation because the wrong target label can cause users to put the right number into the wrong field.
3. Preserve codes character for character
Protected identifiers should be checked character by character, not only visually. Similar characters such as O and 0, I and 1, B and 8, or S and 5 are easy to confuse in poor scans or low-resolution PDFs. When a source is unclear, verify against the issuing bank or original electronic record rather than guessing.
4. Treat spacing as presentation, not identity
IBANs and long account numbers are often grouped with spaces for readability. Those spaces may not be part of the identifier itself. A target document can usually preserve the source grouping, but the translator should not insert punctuation that could be mistaken for part of the account number. When a form requires an unspaced value, keep a clean machine-readable version available.
5. Keep institution names and codes aligned
If the document names a bank and gives a SWIFT/BIC code, both should point to the same institution. Translating the bank name using an unofficial or historical target-language form can create doubt even when the code is correct. Prefer the bank’s own official target-market name where available, and preserve the code unchanged.
6. Distinguish beneficiary identity from payment routing
A beneficiary name identifies the recipient; a routing identifier directs the payment through the banking system. Do not “improve” a beneficiary name into a translated company name unless the account holder officially uses that form. A translated commercial description is not automatically the legal account name accepted by the bank.
7. Preserve currency and charge instructions
Payment details often specify currency, fee allocation and correspondent-bank conditions. Translate labels such as “all bank charges borne by sender” precisely and keep the currency code or explicit currency identity attached to the instruction. Do not silently convert currencies or infer a different payment amount.
8. Verify the final document as a payment user would
A good final check is operational: could a target-language reader enter the data into a banking form correctly? Check that each label points to the right value, line wrapping has not split a code misleadingly, right-to-left text has not reordered Latin identifiers, and no identifier has been altered by auto-formatting.
Twenty banking translation problems that require special care
1. IBANs
An IBAN is an international bank account number with a structured combination of country code, check digits and domestic account information. Translate the label “IBAN” only if local style requires an explanatory phrase; do not translate or localise the identifier itself. Grouping spaces may be preserved for readability, but the letters and digits must remain exact.
When an IBAN appears in a translated invoice or contract, compare it against the source twice: once character by character and once by grouping. If possible, copy the value electronically rather than retyping it. Do not add hyphens simply because another banking system commonly uses them.
2. SWIFT/BIC codes
A SWIFT/BIC code identifies a financial institution and may include branch information. The code itself stays unchanged. The surrounding label can be translated, but the target should make clear that this is a bank identifier rather than an account number.
If a document uses “SWIFT,” “BIC,” or “SWIFT/BIC,” follow the source terminology unless the target bank or institution has a clear house style. Do not create a new acronym. The operational value is the code, and discoverability is improved when internationally recognised terminology remains visible.
3. ABA routing numbers
US routing numbers are specific to the American banking system. Translating “routing number” as the target country’s nearest bank code can be misleading because the systems are not identical. A descriptive target equivalent can explain the function, but the source-system identity should remain clear.
When routing numbers appear beside wire instructions, verify whether the document distinguishes ACH routing from wire-routing details. Do not assume one routing number automatically applies to every transfer type.
4. UK sort codes
A sort code identifies a bank and branch within the UK clearing system. Preserve the digits and conventional grouping. Translate the label functionally, but do not relabel it as an IBAN component or generic routing number if that would erase the source banking system.
Hyphens may appear as part of the conventional visual format. If the target form requires digits only, use a clean version for data entry while keeping the human-readable grouping in explanatory prose when helpful.
5. Australian BSB numbers
BSB numbers identify Australian bank branches. They should remain exact and should not be translated into another country’s routing vocabulary without explanation. If the target reader is unfamiliar with BSB, a short first-use gloss such as “Australian bank/branch code” can improve usability.
The gloss is explanatory, not a replacement identifier. The original BSB label should remain visible if the payment form or receiving bank expects that term.
6. Indian IFSC codes
IFSC is an identifier used in Indian electronic banking. Preserve the code exactly and keep the acronym recognisable. A translated explanatory phrase may be useful, but the operational code and source banking context should not be normalised into a generic target-country label.
If an OCR scan is involved, inspect letters and zeros carefully. Identifiers are high-risk locations for OCR substitution because their strings do not form ordinary words that spellcheckers can catch.
7. Singapore bank and branch codes
Local payment instructions may use bank code, branch code and account number as separate fields. Translate each label without merging the values. A target reader should be able to reproduce the source field structure accurately.
When the same bank also provides SWIFT/BIC information for international transfers, keep the domestic and international identifiers distinct. Similar-looking codes can serve different payment rails.
8. Beneficiary names
The beneficiary name should match the account-holder identity recognised by the bank. If a company has an official English legal name, use that form where appropriate. If not, transliteration may be safer than inventing a translated company name that the bank does not recognise.
In certified or compliance-sensitive work, preserve the source spelling and add a transliteration or translation only in a clearly secondary form. Do not let the explanatory version replace the legal account name.
9. Bank names
Bank names are institutional names, not generic banking vocabulary. Prefer the bank’s official target-language or international name if it publishes one. Otherwise retain the source name or transliterate it consistently.
A literal translation can be dangerous if it makes the institution look like a different bank or an unofficial subsidiary. Cross-check the bank name against the SWIFT/BIC code where both are present.
10. Branch names and addresses
A branch label may combine an official branch name with an address. Translate address labels and descriptive elements according to project style, but preserve location identity and any official branch designation required by the payment instruction.
Do not abbreviate a branch name so heavily that it becomes impossible to distinguish from another branch. If the target bank form expects a city, branch name or branch code separately, keep those data elements separate.
11. Account numbers
Account numbers are protected data. Do not translate digits into another numeral system unless the bank’s target interface explicitly requires and validates that representation. In most international documents, keeping ASCII digits reduces ambiguity.
Leading zeros are especially important. Spreadsheet software, OCR tools and manual retyping can drop them. Treat the account number as text, not as a mathematical number.
12. Payment references
A payment reference may be a machine-matched identifier, an invoice number or a human-readable description. Determine which. Fixed references should remain exact; descriptive payment-purpose text can be translated if the receiving bank or payee permits it.
If the payment instruction says “quote reference exactly,” treat the entire string as protected even if it contains readable words. The matching system may depend on an exact character sequence.
13. Correspondent and intermediary banks
International transfers may list intermediary institutions in addition to the beneficiary bank. Translate the role labels carefully so users do not enter correspondent-bank details into beneficiary-bank fields or vice versa.
Maintain the relationship among bank name, SWIFT/BIC and account details for each institution. A visually clean target document should still preserve the source routing chain.
14. Payment currencies
If the beneficiary account or payment instruction specifies a currency, preserve the currency code or full currency name. Do not assume the bank will automatically convert at an acceptable rate, and do not replace the source currency with the target reader’s local currency.
A target note can explain the currency, but the operational instruction should remain exact. Currency identity is part of the payment, not decorative metadata.
15. Fee instructions
Wire instructions may specify who bears charges. Translate sender/beneficiary responsibility precisely. A mistranslation can reduce the amount received or create an unexpected fee dispute.
If standard payment abbreviations are used, retain the recognised code where operationally required and provide an explanatory target phrase if the intended reader needs it.
16. Beneficiary addresses
Some payment forms require the account holder’s address for compliance or routing. Translate or transliterate according to the receiving institution’s rules while preserving house number, street, district, city, postal code and country identity.
Do not “clean up” an address into a different location format if that changes official elements. A readable target version can coexist with the source address when compliance requires traceability.
17. Right-to-left documents
Banking identifiers often remain left-to-right inside Arabic, Hebrew or other right-to-left prose. Test the rendered document, because punctuation, spaces and neighbouring labels can visually reorder the code even when the underlying characters are correct.
Never manually reverse an account number or SWIFT/BIC to make it “look right.” Use proper bidirectional text handling and verify copy-paste behaviour.
18. OCR and scanned banking documents
Scans create special risk because codes are poor candidates for language-based error correction. A recogniser that turns 0 into O or 1 into I may produce a plausible-looking string that is operationally invalid.
For high-value or high-stakes payments, verify identifiers against the original digital statement, bank portal or issuing institution. Translation should not become a substitute for source-data verification.
19. Redacted banking details
Documents may mask account numbers for privacy, for example with asterisks and final digits. Preserve the masking pattern and do not reconstruct or infer hidden digits. The fact of redaction is part of the source.
If a target language requires an explanatory label such as “account ending in 1234,” translate the label while keeping only the visible digits supplied by the source.
20. Fraud prevention and verification wording
Invoices and bank instructions increasingly warn users to verify changed payment details independently. Translate those warnings with their full urgency. A softened target sentence can increase fraud risk.
Do not present translated banking details as newly “verified” merely because they have been proofread. Linguistic review checks fidelity to the source; financial verification requires confirmation from an authorised party or institution.
Common failure modes
Retyping every identifier manually. This creates avoidable character risk. Copy protected values electronically where possible, then compare against the source.
Translating account-holder names as ordinary nouns. The bank may recognise only the legal or registered form. Use official names or careful transliteration rather than invented equivalents.
Replacing source banking systems with target-country labels. A routing number, sort code, BSB and IFSC are not interchangeable simply because they all help direct payments.
Dropping leading zeros. Spreadsheet and numerical formatting can silently change account data. Store identifiers as text.
Assuming spaces and hyphens are always part of the code. Treat display grouping separately from identifier identity.
Ignoring currency instructions. The right account with the wrong currency can still create operational problems and unexpected conversion.
Failing to distinguish bank roles. Beneficiary, intermediary and correspondent banks should remain separate in the translated layout.
Trusting OCR or AI output without code-level verification. Fluency is irrelevant if the identifier is wrong.
Worked practice
Practice 1: International invoice. The source lists beneficiary name, bank name, IBAN, SWIFT/BIC, currency and “all charges borne by sender.” Translate the labels and fee instruction, preserve identifiers, verify the official bank name and keep currency identity explicit.
Practice 2: Domestic bank transfer. A source document gives bank code, branch code and account number in separate fields. Preserve the field structure instead of collapsing everything into one generic “routing information” block.
Practice 3: Multilingual beneficiary. The account holder’s legal name is written in a non-Latin script and the bank also provides a Latin-script form. Use the official Latin form for operational payment data and retain the source-script form where identity traceability is useful.
Practice 4: Scanned instruction sheet. A SWIFT/BIC contains characters that OCR reads ambiguously. Do not guess. Verify against an original electronic source or authoritative bank information before finalising.
Practice 5: Redacted statement. An account number appears as ****6789. Preserve the masking exactly. Do not infer the hidden digits from another part of the file unless the translation brief explicitly requires a verified full value from an authorised source.
Practice 6: Right-to-left translation. The Arabic target sentence contains a Latin SWIFT/BIC and IBAN. Keep the identifiers left-to-right and test visual rendering, cursor movement and copy-paste behaviour.
Practice 7: Changed payment details warning. Translate the instruction to independently confirm any change of bank details. Preserve urgency and avoid wording that implies the translation itself verifies the new account.
Practice 8: Correspondent banking. A wire instruction lists both beneficiary and intermediary banks. Keep each institution’s name, code and role grouped correctly so the target reader cannot confuse them.
Using AI, CAT tools and spreadsheets safely
Computer-assisted translation tools can protect numbers and tags, but banking identifiers deserve stronger treatment than ordinary repeated strings. Add them to a do-not-translate or protected-expression list where the tool supports it. Use automated QA to compare source and target alphanumeric sequences, but still perform human verification because spacing and field labels can affect usability.
Spreadsheets are useful for structured banking data, yet they create a specific hazard: automatic number formatting. A leading zero may disappear, long digits may be displayed in scientific notation, and values can be reformatted as dates. Format identifier columns as text before importing or editing them.
AI systems can help explain banking terminology and draft surrounding prose, but they should never be allowed to “clean,” normalise or regenerate account identifiers from memory. Treat every identifier in the source as immutable data unless an authorised banking source explicitly supplies a corrected value.
How this fits the wider eduKate translation system
This article is one specialised owner inside eduKate’s wider translation architecture. The broad method remains Master Art of Translation | The Complete System for Moving Meaning Between Languages. Vocabulary depth and terminology awareness connect to the Vocabulary Learning Hub, while reference, noun phrases, labels and sentence structure connect to How English Works. Banking identifiers add a critical data-integrity layer: some things in a translation must move into the target language, while others must remain exactly themselves.
FAQ
Should an IBAN be translated?
No. The IBAN itself is an identifier and should remain exact. Translate only the label or explanatory text around it.
Can spaces in an IBAN be changed?
Spaces are commonly used for readability, but they are presentation rather than identity. Preserve safe grouping and avoid inserting punctuation that could be mistaken for part of the code.
Should SWIFT/BIC be translated?
The code remains unchanged. The label can be translated or explained, but recognised international terminology should stay visible where useful.
Can a beneficiary name be translated?
Use the legal or official form accepted by the bank. A descriptive translation can be added separately, but it should not replace the account-holder identity.
Are routing numbers and sort codes equivalent?
They serve related routing functions in different banking systems but are not the same identifier type. Preserve the source-system label or explain it rather than pretending they are identical.
Should currency be converted during translation?
Not unless the brief explicitly requires conversion. Preserve the source currency and amount as payment data.
How should scanned bank details be handled?
Verify identifiers against an authoritative electronic source where possible, especially when OCR could confuse similar characters.
Can AI safely translate bank instructions?
AI can assist with explanatory prose, but all account identifiers, bank codes, currencies and payment references need independent verification.
What is the biggest practical risk?
Putting the right-looking value into the wrong field or changing one protected character. Both can make a payment fail or route incorrectly.
What is the simplest rule?
Translate the banking language; preserve the banking identity.
Final checklist
- Have I identified every protected banking identifier?
- Are IBANs, SWIFT/BIC codes, account numbers and routing codes unchanged?
- Are leading zeros preserved?
- Do labels still point to the correct fields?
- Are beneficiary and bank names using official or traceable forms?
- Are correspondent and beneficiary banks clearly separated?
- Is the payment currency unchanged unless conversion was explicitly requested?
- Are fee instructions and payment references preserved accurately?
- Has right-to-left or line-wrap rendering been tested?
- Could a target-language reader enter the payment correctly from the translated document?
Banking translation is a useful model for translation discipline because it shows that not every meaningful element should be transformed. Labels, explanations and instructions need target-language clarity. Identifiers need exact preservation. Strong translation knows the difference. Protect the data, translate the relationships around it, verify the institution and beneficiary identity, and test the final document as a real payment user would.