Why account masking in AP systems directly enables wire fraud
There is a user interface convention that migrated from consumer banking into enterprise finance without anyone re-examining why it existed, and it now sits directly on the path of one of the most expensive fraud categories in business.
Why is masking account numbers on an approval screen harmful?
Because it hides the digits the attacker changed. Masking was borrowed from consumer banking, where it protects the customer from shoulder-surfing. On an approval screen the approver's whole job is to notice a substitution, and a masked field makes the old and new accounts look identical.
- Masking protects a customer viewing their own account from shoulder-surfing. An approver verifying a third party's account has the opposite need.
- Comparing truncated identifiers is a recognition task performed against memory, and it degrades sharply as the visible portion shrinks.
- Total rendering costs nothing, requires no counterparty cooperation, and is the only intervention here that can ship this quarter.
Part of Payment release authorization
Where the convention came from
Masking an account number — showing the last four digits, concealing the rest — originated in consumer contexts for a defensible reason. A customer looking at their own statement in a public place does not need the full number displayed, and concealing it reduces exposure to observation and to screenshots.
The customer already knows their own account. The masked display is a confirmation aid, not a verification aid, and for that purpose four digits is sufficient.
Why the approval context inverts the requirement
An accounts payable approver is doing something structurally different. They are verifying an account belonging to someone else, which they do not know from memory, against a change they cannot independently confirm.
| Consumer viewing own account | Approver verifying a payee | |
|---|---|---|
| Knows the correct value? | Yes, from memory | No |
| Purpose of display | Confirm which account | Verify the account is correct |
| Threat | Observation by a third party | Substitution by an attacker |
| Effect of masking | Reduces exposure | Conceals the substituted portion |
The same interface pattern serves opposite purposes in the two contexts, and the enterprise context inherited it without the analysis.
The comparison task, examined
What does an approver actually do when a masked account is displayed? One of three things, and none of them is verification.
- Nothing. They review vendor name and amount, which are meaningful, and skip the account because four digits convey no information they can evaluate.
- Recognition against memory. For a frequently paid vendor they may recall the suffix. This works until the attacker substitutes an account whose suffix differs — which it always will — at which point the approver must decide whether the change is legitimate, with no basis for deciding.
- Comparison against a prior payment. Rare, because it requires leaving the approval screen. And a legitimate bank change also produces a mismatch, so a mismatch is not diagnostic.
Option two is the interesting failure. A masked display can only ever tell an approver that something changed. It cannot help them evaluate whether the change is legitimate, and evaluation is the entire task.
What full rendering makes possible
Displaying the complete account number, routing code, beneficiary bank and country makes several judgements available that masking forecloses:
- The beneficiary bank has changed from the vendor's historical bank to a different institution.
- The bank is in a different country from the vendor's operations.
- The routing code belongs to an institution inconsistent with the vendor's profile — a regional bank for a multinational, for instance.
- The account is an obvious personal-banking format for a corporate payee.
- The legal name on the account differs in a meaningful way from the vendor's registered name.
None of these is conclusive on its own. All of them are unavailable when the display is four digits.
The objection, and the answer
The objection is data protection: displaying full banking details in an application increases exposure if the application or the screen is compromised.
That objection has force in a consumer context and much less here. The approver is authorised to make a payment to this account; concealing it from them does not reduce their access to it, because the payment executes to the full number regardless. Masking protects the display, not the data, and the data is already in the system the approver is using.
Where the concern is screenshots or shoulder-surfing in an open office, the proportionate answer is reveal-on-interaction — the full value shown when the approver acts on it — rather than permanent concealment.
The change-flag, which matters more than rendering
If only one change is made, make this one. When a payee's banking details differ from the last payment, the approval screen should show, prominently and without navigation:
⚠ BANK DETAILS CHANGED since last payment (14 Jan 2026)
Previous Barclays Bank UK 20-00-00 58473920
New Revolut Ltd 04-00-75 99328470
Changed 2 days ago by: [who made the change in your system]That rendering makes the decision possible. Everything else in this article is a refinement of it.
Where masking is right and where it is wrong
| Context | Mask? | Why |
|---|---|---|
| Customer statement or receipt | Yes | Protects the account holder from bystanders |
| Support agent screen | Yes | Agent does not need the full number |
| Payment approval screen | No | The approver's task is to detect substitution |
| Signed statement | Never lossy | Mask the display, sign the full value |
The rule that follows is narrow: abbreviate for display if you must, but the full value must be inside the signed statement and the verifier must compare the full value. Truncation where nothing sits behind it means a different account could produce the same display.
Objections and honest limits
“PCI and privacy rules require masking.” They govern cardholder data and personal data in specified contexts. A vendor's own bank account on an internal approval screen is usually neither, and the requirement is frequently assumed rather than checked.
“Approvers would not notice the full number anyway.” Then show the delta rather than the number: what it was, what it is becoming, when it last changed and who changed it. That is three lines and it is what the approver can actually act on.
Fixing the approval screen
- Show the full account and routing number. On the approval screen only.
- Show the previous value beside it. A change is far easier to see than a value.
- Show when it last changed and by what path. Import, API, portal or support ticket.
- Sign the full value, mask only the display. So verification compares the whole thing.
Terms used here
- Masking
- Displaying only part of a value. Protective where the risk is disclosure, harmful where the task is detecting change.
- Delta rendering
- Showing what a field was and what it is becoming, rather than only its new value.
- Lossy truncation
- Discarding characters so that different underlying values produce an identical display.
Frequently asked questions
Is full rendering a data protection problem? The approver is already authorised to pay this account and the system already holds the number. Masking protects the display rather than the data. Reveal-on-interaction addresses open-office concerns proportionately.
What if our AP system cannot be changed? Most permit field configuration on approval screens. Where they do not, the change-flag can frequently be surfaced through a report or an adjacent workflow.
Does this actually stop fraud? It makes substitution visible to an attentive approver. It does not verify that a change was requested by the vendor, which requires a signal from the vendor.
How do we know if this affects us? Screenshot your approval screen and count how many of the five material fields are rendered in full. Most organisations find the answer is one or two.
Doesn't PCI require masking? PCI governs cardholder data. A vendor's bank account on an internal approval screen is generally outside it, and the requirement is often assumed rather than verified.
What should the approver see instead? The full account and routing number, the previous value, when it last changed and through which path.
Can we mask anywhere? Yes, for display, provided the full value is inside the signed statement and verification compares the full value.
Where this fits in Manav
Manav renders the full beneficiary details and the delta from what was on file, binds the approver's signature to that exact payload, and has the payment service recompute the digest before it releases funds.
Sources and further reading
- FBI IC3 2025 Internet Crime Report
- AFP — Payments Fraud and Control Survey
- Research on visual comparison and recognition of alphanumeric identifiers.
- NAIC — life insurance and annuities consumer resources