Masking a bank account number means replacing most of its digits with symbols such as X or asterisks, so only a few, usually the last four, stay visible. Do it on every screen, statement, export and log where people don't need the full number, and encrypt or tokenize the full number wherever it is stored. Masking hides data. It doesn't confirm who owns the account, so it protects you from leaks, not from paying the wrong party.
This guide covers what masking means, what U.S. rules say about it, how to apply it in the places your team actually handles account numbers, and where it stops being enough.
TL;DR
- A masked number shows only a few characters, typically the last four, such as XXXXXX2134. The full number still exists behind the mask.
- Showing the last four digits on receipts and statements is common practice. Regulation E allows it for terminal receipts, and no broader federal rule dictates the format on statements.
- Stored ACH account numbers have a separate requirement: Nacha's data security rule requires large originators and service providers to render them unreadable at rest.
- Restrict full-number access by role, require multi-factor authentication, and log every unmasked view.
- Masking doesn't verify the payee. Pair it with a name-to-account check before money moves.
Table of Contents
- What a masked bank account number means
- How many digits to show
- What U.S. rules require
- How to mask account numbers in each place they appear
- Masking doesn't verify the payee
- Where Vopify fits
- Perspective
- Building a masking policy: a short checklist
- FAQ
- Sources
What a masked bank account number means
A masked account number is a display format. The system keeps the real number, but shows a shortened version to anyone who doesn't need the whole thing. A typical result looks like "XXXXXXXX1234".
Organizations do this for three reasons:
- Breach damage. If a screenshot, report or log leaks, a masked number gives a fraudster little to work with. One consumer-facing explainer says masking makes it harder for fraudsters to access account information after a breach or identity theft is a general claim; the narrower, checkable point is that the last four digits alone do not allow a transfer.
- Need-to-know access. An AP clerk matching an invoice to a supplier record needs to recognize the account, not read every digit aloud.
- Compliance posture. Several rules, covered below, expect you to protect account data on paper, in transit and in storage.
Masking is different from encryption. Masking changes what people see. Encryption changes what is stored. You usually need both, and the rules treat them separately.
How many digits to show
The common answer is the last four. That is not arbitrary. Under Regulation E, a receipt at an electronic terminal such as an ATM may show only a number or code that identifies the account, and that number or code need not exceed four characters to comply, so masking to the last four is permitted.
Business software follows similar patterns, with some flexibility:
| System behavior | What is shown | Source |
|---|---|---|
| Oracle PeopleSoft Financials | Masked to 16 characters regardless of original length, with a two-digit system prefix and the last four digits | Oracle documentation |
| Oracle Cloud SaaS Financials | Users can unmask up to the first or last six digits | Oracle documentation |
| Terminal receipts under Regulation E | A number or code identifying the account, no more than four characters required | America's Credit Unions |
The PeopleSoft approach solves a real AP problem. When two accounts share the same last four digits, the system assigns a sequential prefix, "00" to the first and "01" to the second, so staff can still tell the records apart. If your supplier master has thousands of records, plain last-four masking will produce collisions. Plan for them.
A practical rule: show the fewest digits that let a person recognize the record. Four is the usual floor and a safe default. Showing both the first and last few digits narrows the guesswork for an attacker, so avoid it unless a workflow demands it.
What U.S. rules require
There is no single federal law that says "mask account numbers this way." What exists is a patchwork. Knowing which piece applies to you prevents both over-engineering and gaps.
Statements and receipts
Most banks truncate the number on printed or mailed statements, showing the last four digits, but this is a security practice rather than a federal requirement. The FACTA truncation rule covers electronically printed point-of-sale receipts, not bank statements.
America's Credit Unions quotes its compliance specialist as saying that, to her knowledge, no other federal requirement beyond Regulation E dictates showing the full number or shortening it on statements or receipts. In other words, it is a business decision. Make it deliberately and write it down in your policy.
Payslips are a related case. Many employers mask the deposit account on pay stubs, and states can add their own content rules. California employers, for example, should review electronic pay stub requirements before they change what a stub displays, so that masking never removes a field the state requires.
Stored ACH account numbers: the Nacha rule
This is the rule that matters most to finance teams. Nacha's Supplementing Data Security Requirements rule requires each non-consumer originator that is not a participating financial institution, each third-party service provider, and each third-party sender with ACH volume above 2 million entries a year to render account numbers unreadable when stored electronically. Phase 2 took effect on June 30, 2022.
The earlier phase applied to parties with six million or more ACH payments a year from June 30, 2021, according to Nacha's end-user briefing. The rule is neutral about the method. Acceptable options include encryption, truncation, tokenization, destruction, or having the financial institution store, host or tokenize the numbers.
Two details trip teams up:
- Access controls are not enough. Nacha states that passwords and similar access controls don't meet the standard on their own. Even with restricted access and physical security, electronic data at rest must still be rendered unreadable.
- Active use is different from storage. When someone needs the full number to perform a customer service function or conduct authorized business, the data counts as active, not at rest. The unreadability requirement then doesn't apply, but the number must still be protected from unauthorized use through passwords and other access controls.
The rule also reaches beyond consumer data. Basis Theory's explainer notes that it includes business-to-business transactions across accounts payable and accounts receivable systems. If your AP system holds supplier bank details, it is in scope when your volume or role meets the thresholds.
Safeguards Rule
Financial institutions under the FTC's jurisdiction face the Safeguards Rule (16 CFR Part 314). The 2021 final rule requires access controls that are reviewed periodically, with technical and physical controls that let only authorized users in and limit each user to the customer information they need for their duties.
Legal commentary on the rule adds that it calls for multi-factor authentication for anyone accessing an information system, using at least two of knowledge, possession and inherence factors. It also requires policies to monitor and log authorized users' activity, and encryption of customer data at rest and in transit externally.
Sharing account numbers
The Gramm-Leach-Bliley Act bars financial institutions from disclosing account numbers for credit card, deposit or transaction accounts to a nonaffiliated third party for marketing, even when the consumer hasn't opted out, per the FTC's compliance guide. If you are a bank or similar institution, that is a hard limit on exports and data sharing.
Whether these rules apply to you depends on your entity type, volume and role. If you are unsure, ask your compliance officer or outside counsel. This article is not legal advice.
How to mask account numbers in each place they appear
The exposure usually isn't the main database. It is the spreadsheet, the log line and the screenshot. Work through each surface.
Screens and supplier records
Display the masked form by default. Reveal the full number only to roles that need it, and only on request. Enterprise systems already model this: Oracle's payroll tooling uses its HCM Encryption Framework to encrypt and mask bank account numbers in the database, and after encryption the numbers appear masked on pages unless a user holds a role that allows viewing unmasked data.
The same documentation shows the pattern to copy. Oracle's payroll guidance describes Bank Account Admin roles that let specified administrators see unmasked numbers, and notes that direct-deposit entries create audit records that can themselves be masked after encryption.
Statements, reports and exports
Decide the default and apply it to every template. Reports built for review, such as payment run summaries, aging reports and approval packets, almost never need the full number. Remove it at the template level so no one has to remember to redact. If a report must carry the full number, treat the file as sensitive: restrict where it can be sent and how long it lives.
CSV exports deserve special attention. A masked screen means little if "Export all" writes the clear number to a laptop.
Applications, APIs and logs
For developers, the order of operations matters:
- Tokenize or encrypt at the point of capture. Store a token or ciphertext, not the clear value. Nacha lists encryption, truncation and tokenization among the acceptable ways to protect data at rest.
- Mask in API responses by default. Return the last four digits plus a record ID. Add a separate, permissioned endpoint for the full value, and rate-limit it.
- Scrub logs. Never log request bodies that contain account numbers. Add a redaction filter to your logging library, and test it with a real-looking number.
- Mask in error messages and analytics. Crash reports and support tools are frequent leak paths.
- Mask in lower environments. Don't copy production data to test systems unless the numbers are masked or replaced.
For your own supplier data, the stronger design is to avoid holding more than you need. If a verification service returns a match result rather than account details, your system stores a result, not another copy of the number.
Access control and audit
Masking only works if unmasking is controlled. A workable minimum:
- Limit full-number access to named roles, such as AP supervisors or treasury, and review the list periodically.
- Require multi-factor authentication for every system that can unmask.
- Log who unmasked which record, when and why, and review those logs. The Safeguards Rule expects monitoring and logging of authorized users' activity.
- Remember Nacha's point: access controls govern active use, but stored data still has to be unreadable.
Masking doesn't verify the payee
Masking protects the number you hold. It says nothing about whether a number you receive belongs to the person you think it does.
That gap is where payment fraud lives. In business email compromise, a criminal impersonates a supplier or executive and asks you to send funds to a new account. The FBI's Internet Crime Complaint Center describes BEC as a $55 billion scam that has been reported in all 50 states and 186 countries. Every account number in those cases may have been handled perfectly, masked on screen and encrypted in storage, and the payment still went to a fraudster.
The control that closes the gap is verification before payment: confirm that the name on the account matches the payee you intend to pay, and hold the payment when anything about the bank details has changed. Our guides cover how to validate vendor bank accounts, why AP must hold payment first after a bank change request, and how risk-based verification lets you spend effort where the exposure is highest. For U.S. ACH specifically, see the five steps to prepayment Nacha account validation and how to pair ACH prenotes with instant name checks.
Think of the two controls as a pair:
| Control | Protects against | Does not protect against |
|---|---|---|
| Masking and encryption | Leaks, over-broad access, breaches of stored data | Paying a fraudulent or mistaken account |
| Name-to-account verification | Misdirected payments, impersonation, fake bank details | Exposure of the numbers you store |
A mature AP process has both.
Where Vopify fits
If your suppliers or payees hold accounts outside the U.S., verification is where we help. Vopify checks, in real time, that the IBAN you were given matches the account holder name you expect, for both individuals and businesses. You enter a name and an IBAN, and results come back in under two seconds. There are no contracts or platform fees to start, and no integration is needed.
You can run a single lookup or upload a CSV to check supplier data in bulk, which suits a periodic sweep of your vendor master. Coverage includes SEPA countries in the Eurozone, India, Indonesia, South Korea and China (Alipay); the coverage page lists the supported networks. Pricing is pay-as-you-go at $0.70 to $1.00 per verification, or a monthly plan: Starter at $240 per month, Growth at $750 per month and Scale at $2,000 per month.
Start with a single payee verification, or look at bulk IBAN verification if you have a supplier file to check. If your U.S. team is new to IBANs, read what US finance teams must know about converting bank account numbers to IBANs first.
Perspective
We see the same pattern in finance teams. They invest in masking, role-based access and encrypted storage, and then approve a payment because an email said the bank details changed. The data was protected. The payment was still wrong.
Our view is that masking and verification answer different questions. Masking asks who may see this number. Verification asks whether this number belongs to the party we mean to pay. A process that answers only the first has a blind spot right where the money moves.
That is why we built Vopify around a name and an IBAN, with an answer in under two seconds and no contract or integration to get started. The check should be cheap and fast enough that nobody skips it, including on the one urgent invoice that arrives on a Friday afternoon. Mask what you store, verify what you pay.
David
Building a masking policy: a short checklist
Write these decisions down so audits and new hires don't have to guess:
- Inventory. List every system, report, export and inbox where account numbers appear.
- Set defaults. Mask to the last four digits everywhere unless a documented need exists. Handle last-four collisions deliberately.
- Protect storage. Encrypt or tokenize stored numbers. Check whether the Nacha thresholds apply to your role and volume.
- Control unmasking. Name the roles, require multi-factor authentication, log every reveal.
- Clean the edges. Scrub logs, test data, support tickets and shared spreadsheets.
- Verify before paying. Match payee name to account for new suppliers and any bank detail change, and hold payments until the match is confirmed.
- Review. Revisit access lists and logs on a schedule, and after any staffing or system change.
FAQ
Is it safe to share the last four digits of a bank account number?
The last four digits alone don't allow anyone to move money, which is why they are the common display standard on receipts and statements. They are still personal financial information, so keep them out of public channels. Scammers sometimes use them to sound credible when impersonating a bank or supplier.
Is masking bank account numbers required by law?
Not as a general rule. Regulation E allows terminal receipts to show a shortened number, and there is no broader federal rule on statement format. Stored ACH account numbers are a different matter: Nacha's rule requires covered parties to render them unreadable at rest, and the FTC's Safeguards Rule sets access and encryption expectations for covered financial institutions.
What is the difference between masking and encryption?
Masking controls what a person sees on a screen, report or receipt. Encryption scrambles the stored value so that it can't be read without a key. Masking alone leaves the clear number in storage, so Nacha-covered organizations need encryption, tokenization or another approved method for data at rest.
Can a masked account number tell me who owns the account?
No. A masked number is only a shortened display of an account identifier and says nothing about the holder. To confirm ownership before you pay, run a name-and-account verification check. Vopify does this for IBAN accounts in the countries on its coverage page.
Sources
- To Mask or Not Mask | America's Credit Unions
- Masking Bank Account Numbers | Oracle PeopleSoft
- Options for System Security | Oracle Cloud SaaS Financials
- Bank Statement Content | LegalClarity
- California Employers: Nine Required Fields for Electronic Pay Stubs
- Supplementing Data Security Requirements | Nacha
- Supplementing Data Security Requirements, end-user briefing | Nacha
- Breaking down the 2022 Nacha Data Protection Requirements | Basis Theory
- Standards for Safeguarding Customer Information | Federal Register
- The FTC's Strengthened Safeguards Rule | Debevoise Data Blog
- How To Comply with the Privacy of Consumer Financial Information Rule | FTC
- Encryption Source Records | Oracle PeopleSoft HCM
- Understanding Data Encryption for Payroll for North America | Oracle
- Business Email Compromise: The $55 Billion Scam | IC3