What the Bank Account Masker does
Before you paste a support email into a ticket, attach a payment file to a bug report or share a spreadsheet with a supplier, the account identifiers in it need to go. This page finds card numbers, IBANs, US routing numbers, UK sort codes, Indian IFSC codes and UPI addresses in text or a CSV, masks them so only the last few characters remain, counts what it found, and then re-scans its own output to check nothing recognisable was left behind.
Detection is deliberately conservative: a card number must pass the Luhn check, an IBAN must pass mod-97 and a routing number must pass the ABA checksum before anything is masked. That keeps the report free of false positives - an order number is not mistaken for a card - at the cost of missing an unusual or deliberately obfuscated identifier, which is why the page tells you to read the output rather than trusting it.
Every byte stays in this browser tab. A tool for removing sensitive data would be a poor one if using it meant uploading the sensitive data first.
How to use it
- Paste the text or CSV, or choose a .txt, .csv, .log or .md file. Nothing is uploaded either way.
- Set how many characters to leave visible. Four is the convention for a card; for an IBAN, fewer is safer, because the country, bank and branch parts are often guessable from context.
- Tick the identifier types to look for. The loose '6 to 17 digit run' detector catches bare account numbers but also order numbers and dates, so it is off by default.
- For a CSV, tick whole columns to mask - an IBAN column, an account column - and every cell in them is masked regardless of format.
- Read the findings and the masked text. If anything still matches after masking, the page says so and you should reduce the visible characters.
- Copy the result or download the masked file, and download the counts-only report if you need a record of what was removed.
Reading the results
'Identifiers found' is the number of matches that passed their checksum test. 'Still matching after masking' should always be zero; if it is not, you are leaving too much visible.
The counts table tells you what kind of data was in the file, which is often more useful than the masking itself - a support inbox that turns out to contain card numbers is a process problem.
Masking hides digits, not context. A name, an address, an amount and a date sitting next to a masked account number can still identify a person completely.
A clean scan does not mean the text is clean. The detectors look for specific, checksum-verified shapes; anything else - a passport number, a national insurance number, a bare account number with the detector off - passes straight through.
Worked example: a support email, before and after
The example email contains 4111 1111 1111 1111 (a card number that passes Luhn), GB82 WEST 1234 5698 7654 32 (an IBAN that passes mod-97), the sort code 20-00-00, the IFSC SBIN0000001, the UPI address ramesh.kumar@oksbi and the routing number 021000021. That is six identifiers across four countries in one short message, which is realistic for a shared billing inbox.
With four characters kept, the card becomes ** 1111 and the IBAN ** 32 - the separators survive, so the shape is still readable and a human can confirm which account was meant without being able to pay it.
The address [email protected] is left alone. It looks like a UPI ID at a glance, but the handle is followed by a dot and a letter, which means a domain, so the detector skips it. That distinction is the difference between a useful redaction and one that mangles the message.
Why the detectors use checksums
A redaction tool that flags every long digit run produces output nobody trusts: invoice numbers, timestamps, product codes and telephone numbers all disappear, the masked text becomes unreadable, and people stop using the tool. Requiring a Luhn pass for a card number, a mod-97 pass for an IBAN and the ABA checksum for a routing number cuts false positives to almost nothing.
The trade-off is explicit. A card number written with full stops between the groups, or an account number with no checksum at all, will not be caught. That is why the loose digit-run detector exists as an option, why the page re-scans its own output, and why the last instruction is always to read the result.
How much to leave visible
Four digits is the card convention because it is what receipts show and what a customer can recognise without it being useful to a thief. It is not a universal safe number. For an IBAN, the last four characters plus the country code narrow the account considerably when the bank is known from context; for a short account number, four characters can be most of it.
If the purpose is to let a colleague match a record rather than to let a customer recognise their own card, zero visible characters is usually right. Masking is not encryption - there is no key and no reversal - so the only question is how much residual information the recipient needs.
Limitations: what the result does not prove
- This is a redaction aid, not a compliance control. For a regulator, a court or a breach notification, a person must read the output.
- Detection is checksum-based and conservative. Obfuscated, unusually formatted or checksum-free identifiers can pass through untouched, and a clean scan is not proof that the text is clean.
- Masking hides digits only. Names, addresses, amounts, dates and email addresses are left in place and frequently identify a person on their own.
- Masked data cannot be recovered - there is no key. Keep the original if you still need it.
- The tool checks identifiers. It cannot tell you whether an account exists, whose it is, or whether sharing the file is lawful in your jurisdiction.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- ISO/IEC 7812 - Identification cards: issuer identification numbers - checked 19 Sep 2026
- ISO 13616 - International bank account number (IBAN) - checked 19 Sep 2026
- PCI Security Standards Council - PCI DSS
- UK Information Commissioner's Office - anonymisation guidance
Frequently asked questions
Is my data uploaded when I use this?
No. The scan, the masking and the re-check all run in your browser, and you can confirm that in the network panel - no request carrying your text is made. That is deliberate: a tool for removing sensitive data should not require you to send it somewhere first.
How many digits of a card number can I safely show?
Four is the industry convention and is what receipts print, because it lets a cardholder recognise their own card without being useful to anyone else. PCI DSS permits the first six and last four to be displayed; it does not require you to show any, and showing none is safer when the recipient does not need to recognise the card.
Why was a number in my file not masked?
Because it did not pass the checksum for its type. Card numbers must satisfy Luhn, IBANs mod-97 and US routing numbers the ABA check - a mistyped or invented one fails and is left alone. For bare account numbers with no checksum, turn on the '6 to 17 digit run' detector and accept that it will also catch order numbers.
Can masked numbers be recovered?
Not from the output. The characters are replaced, not encoded, and there is no key. Keep the original file if you still need the full values - masking is one-way by design.
Does this make a file GDPR compliant?
No. Masking an account number reduces one kind of risk; it does not anonymise a record that still carries a name, an address or an email. Whether a file may be shared is a legal question about the whole record and its purpose, not a property of the digits in it.
Can I mask a whole CSV column?
Yes. Paste or load the CSV and the column headers appear as checkboxes; every cell in a ticked column is masked regardless of whether it matches a detector. That is the reliable route for an account-number column, where there is no checksum to test against.
Why is an email address not treated as a UPI ID?
Because a dot followed by a letter after the @ means a domain. ramesh@oksbi is a UPI handle; [email protected] is an email address, and masking it would corrupt the message for no benefit. Email addresses are not in scope for this tool.
What should I do if the report says something still matches?
Reduce the number of visible characters and run it again. A residual match normally means you kept enough of an IBAN or a sort code that the pattern still recognises it, which means a person could too.
Last reviewed by the A2Z.Tools team against the sources listed above.
