Zero Trust in payments: how zero trust moves from the network into transaction approval procedures
The zero trust model has long been the standard for protecting networks and system access. Yet today the most expensive incidents happen not in the network but in the payment approval process — and that is exactly where Zero Trust has to move next.
What Zero Trust is and why it has outgrown the network
Zero Trust is an architectural approach in which no user, device or request is considered trusted simply because it is "inside" the perimeter. The industry's reference document, NIST SP 800-207, puts it plainly: access is granted per session, based on policy and context, and trust is continuously re-evaluated.
For IT teams this meant abandoning the idea of a "safe internal network". For finance teams the consequence is even more important: an "internal" email from the CFO, a call from a "familiar" counterparty or a message in the corporate messenger is not, by itself, proof that a request to transfer funds is legitimate.
The trusted-channel myth
Most payment procedures are still built around the channel: if a request came from a corporate mailbox, in a familiar voice or from a known number, it is considered genuine. This is precisely the logic exploited by BEC attacks, supplier bank-detail fraud and deepfake calls impersonating executives.
The key shift in thinking: a communication channel is only a transport for the request. Trust must come from the checks the process performs, not from where or whom the message came from.
When an organisation brings Zero Trust into payments, it stops asking "does this sound like the real executive?" and starts asking "has this request passed every independent check the policy requires?"
Five Zero Trust principles for transaction approval
- Verify every request explicitly. Every payment and every change of bank details is checked against policy, regardless of the requester's seniority or the urgency.
- Least privilege. Amount limits, a list of approved beneficiaries and separate rights to create, approve and release a payment.
- Assume breach. Design the process as if an executive's mailbox or account were already compromised: no single channel can both initiate and confirm a transfer.
- Independent confirmation. Non-standard operations are confirmed out-of-band — via a pre-registered contact, not via the channel the request arrived through.
- Continuous risk assessment. The amount, a new beneficiary, an unusual time, a new country or changed bank details automatically raise the level of scrutiny.
What the process looks like in practice
In a mature model a payment passes through several independent "gates", and any of them can stop the operation. No single person and no single channel can complete the whole chain alone.
An important detail: the checks must be built into the system (TMS, ERP, online banking) rather than exist only in a policy document. Any rule that can be bypassed "in exceptional cases" will inevitably be turned into an exception by an attacker.
Where to start
- Map every route by which payment instructions and bank-detail changes reach the company.
- Split the roles of creating, approving and releasing a payment between different people and accounts.
- Store the counterparty contact directory in master data and forbid changes to it without a separate procedure.
- Configure risk thresholds that automatically trigger additional verification.
- Test the process regularly with BEC and deepfake-call scenarios.
Zero Trust in payments is not a product but a discipline: trust is never granted to a channel; it is earned by verification every single time. — Sentinel Ledger Editorial
