The Threat Model for Payment Systems

A threat model for payments starts with the simple fact that payment systems move money, and money attracts determined attackers. Criminals do not attack a payment hub for fun, they attack it because a single successful fraud can be worth millions of pounds. A threat model therefore lists the attackers, their motives, their methods and the assets they want. The assets include customer accounts, payment instructions, credentials, encryption keys, message queues and nostro accounts. Once the assets are clear, the team can decide which controls matter most and where a single failure would cause the greatest loss. External attackers usually start with phishing, malware or stolen credentials. A finance officer at a UK company receives an email that looks like it came from a supplier, clicks a link, and enters a password on a fake login page. The attacker then uses that password to log into the payment portal and submit a fraudulent payment of 180,000 euros to an account they control. A strong threat model assumes that passwords will be stolen, and therefore requires multi factor authentication, payment limits, dual approval and anomaly detection as additional layers. No single control is trusted on its own. Insider risk is just as important, because staff inside a bank or a corporate customer already have access. A payment operations analyst who can create, approve and release payments on their own could send 250,000 dollars to a personal account and hide the transaction. A good threat model therefore requires segregation of duties, so that no one person can complete a high value payment alone. It also requires logging of every action, regular review of privileged access, and alerts when a user performs an unusual action, such as changing a beneficiary just before a large payment. Payment systems also face attacks on the messages and files that carry instructions. An attacker who can alter a pacs.008 in transit could change the beneficiary account or increase the amount from 10,000 pounds to 100,000 pounds. An attacker who can inject a fake pain.001 file into a corporate upload could create hundreds of fraudulent salary payments. The threat model must therefore cover message integrity, file signing, secure channels and validation at every hop. A message that cannot be trusted must be rejected, even if it looks correct on the surface. Finally, the threat model must cover third parties, vendors and human error. A bank that connects to SWIFT, a clearing system and a cloud provider depends on each of them to stay secure. If a vendor is compromised, the bank can be exposed through that connection. If an operator pastes the wrong file into the wrong environment, a test payment can reach production. The threat model therefore includes vendor assessment, network segmentation, environment separation and strict change control. Security is not one product, it is a set of controls that together reduce the chance that any single attack succeeds. A worked attack scenario makes the threat model concrete. A finance officer at a UK company receives an email that appears to come from a supplier, with a new bank account for payment. The officer clicks the link, enters the portal credentials on a fake page, and the attacker now has the login. The attacker creates a payment of 180,000 pounds to a mule account, and because the officer is an authorised user, the payment passes the first checks. It is stopped only because the fraud system flags a new beneficiary, a large amount, and a payment outside normal hours. The controls that mattered were the new beneficiary cooling-off period, the velocity check, and the out-of-hours rule. A threat model that does not name these controls is not a threat model; it is a list of worries. Insider risk deserves the same rigour as external attack, because insiders already have access. A payment operations analyst who can create, approve, and release payments on their own could move money without any second person knowing. The controls are segregation of duties, so no single person can complete a payment alone; dual authorisation for payments above a threshold; and maker-checker workflows where the checker is a different person from the maker. A business analyst specifying a payment system must define the authorisation matrix, the thresholds, and the audit trail for every action. If the system cannot prove who did what and when, it cannot pass an audit, and it cannot be trusted with customer money.