Embedded APP Fraud: How Payment Initiation Services Are Reshaping the Attack Surface

Authorised Push Payment fraud has evolved beyond the consumer and SME playbook into institutional payment flows, where the economics of attack are radically different. Payment Initiation Services, which sit between corporates and their banks, are now routinely compromised or mimicked in attacks that exploit a trust model that was never designed for adversarial third parties. TrustSphere's assessment is that financial institutions have fundamentally underestimated the APP fraud risk embedded in payment initiation, and that the market response so far treats this as a connectivity problem rather than a security boundary.

The risk is not new to payments. What has changed is scale, sophistication and the institutional target base. Until 2024, APP fraud was described as a consumer and small-business problem. Larger corporates have benefited from payment batching, wire transfer controls, execution governance and banking relationships that made them appear less vulnerable. But the shift to API-driven payments, Open Banking and real-time payment schemes has fractured that governance model. Corporates now connect directly or via third-party payment platforms to their banking infrastructure, and that connection is itself a point of failure that traditional controls do not monitor.

The attack pattern is specific: fraudsters either compromise a genuine payment platform or build a convincing replica, then either inject false payees into a legitimate payment run or intercept and redirect a standing instruction. The victim usually does not know a compromise has occurred. The bank often cannot distinguish the fraudulent instruction from a legitimate one, because the instruction comes from an authenticated, whitelisted source (the payment platform itself). By the time the contradiction surfaces in a reconciliation, the money has moved.

Institutional Payment Platforms and the Trust Model

Payment Initiation Services are contractually trusted by corporates but not explicitly authorised by banks. A corporate engages a platform to manage payment execution, reconciliation and reporting across multiple bank accounts. The bank sees an instruction that has been signed with legitimate credentials and originated from a known account. The platform, in turn, is expected to enforce its own governance: validating payees, checking payment amounts against internal rules, and reporting anomalies. If the platform fails, the bank does not have a secondary control.

Current APP victim protection frameworks treat this as a consumer fraud problem and expect the bank to detect the fraud. That model breaks when the fraud originates inside an institutional service layer. The bank's control is the signature, not the authenticity of the underlying instruction. The platform is responsible for governance but is not required to implement the same real-time exceptions that consumer banking has deployed.

TrustSphere engagement data from 2026 shows that APP fraud cases involving payment platforms fall into three categories. The first is genuine platform compromise, typically via credential theft or application vulnerability, affecting a small number of instances but often with large transaction volumes. The second is social engineering directed at platform operators, who have legitimate access to payee maintenance and payment execution but can be tricked into changing standing orders or authorising ad-hoc payments. The third is replica platforms, often hosted on lookalike domains or credible cloud infrastructure, which capture credentials or banking details from corporates who connect to them unaware.

Regulatory and Market Context

The Payment Services Regulation 2 framework in the UK requires firms to implement strong customer authentication for remote payments, but the requirement applies only to the initiating point (the consumer or payment originator). A corporate using a payment platform is already authenticated; the platform's own connections to the bank are often exempt from SCA because they are considered institutional. The EBA's Guidelines on payment initiation services make no explicit requirement for PIS providers to implement fraud detection or real-time exception handling. The presumption is that the corporate customer will implement its own controls.

That presumption is sound in principle but routinely fails in practice. Corporates often lack real-time visibility into payment execution. Reconciliation happens daily or weekly. By then, fraudulent payments can be scattered across multiple banks and intermediaries. The FCA's APP Reimbursement Guidance requires firms to reimburse customers for Authorised Push Payment fraud in most cases, but it does not extend to institutional payments where the authorised party is a payment platform or a rogue operator within one. The reimbursement obligation dissolves when institutional controls are involved.

The Attack Surface in Practice

A worked scenario: a FTSE-250 corporate holds accounts across four banks and uses a payment platform to manage disbursements. The platform connects to each bank via API, with credentials stored in a secrets management system. An attacker compromises that system and gains access to the API credentials but not the corporate's banking login. From that point onward, the attacker can create new payees or modify existing ones. The bank receives payment instructions signed with legitimate API keys, from a whitelisted system, for amounts consistent with the corporate's normal payment run. The first indication of compromise is when the corporate's own payment platform reports mismatches between what it believes it sent and what the bank confirms it received, or when the payee reports receipt of payment from multiple sources. By then, ten to fifteen days have passed.

The control failure is not security but visibility. The corporate's finance team cannot see the platform's API logs in real time. The bank cannot see the corporate's internal payee maintenance without intrusion into the corporate's own systems. The platform cannot reliably confirm the authenticity of its own connections without additional cryptographic binding. Each party operates within its own trust boundary and has no efficient way to detect when that boundary has been crossed by an adversary acting from inside the institutional service layer.

What This Means for Each Stakeholder

Tier 1 banks face a reimbursement liability that they may not have priced into APP fraud cases involving institutional payment services. Their controls are designed for consumer fraud, where the bank's signature on an instruction is a strong signal of authenticity. In the institutional context, that signal is weaker. Many banks have no real-time exception capability for API-initiated payments and rely on downstream reconciliation, which is too late. The largest risk is to cash management teams processing high-volume payment runs with minimal exception handling.

Challenger banks and neobank payment processors lack the correspondent banking relationships and real-time settlement infrastructure to implement institutional controls effectively. They are often the target of choice for fraudsters precisely because their exception handling is weaker and their outbound payment corridors are less visible. The economics favour fast-growing platforms over robust ones, and fraud prevention is capital-intensive for both platform and bank.

Payment Initiation Service providers face existential reputational risk. A single compromise affecting a large corporate can trigger immediate termination of the service contract and public disclosure. PIS providers are not insured against APP fraud and typically pass the loss back to the corporate customer. The market response has been to invest in authentication and encryption, but those address account takeover, not social engineering or rogue operator scenarios.

Technology vendors selling fraud detection solutions have positioned themselves around consumer APP fraud and high-velocity transaction monitoring. Few offer real-time payee validation, standing order anomaly detection or institutional payment flow monitoring. The gap is not technical but commercial: the institutional APP fraud market is smaller and more bespoke than consumer fraud. Vendors have not yet built productised solutions for this problem.

Regulators and supervisors have flagged APP fraud in Operational Resilience expectations, but most guidance treats it as a consumer protection issue. The PRA's recent operational resilience notices do not explicitly address institutional payment flow integrity. Supervisors are beginning to ask firms about APP fraud in institutional contexts, but the questions are still framed around reimbursement capability rather than prevention.

Corporates often underestimate their exposure because they assume their banking relationship and internal controls provide protection. Many have not conducted forensic analysis of what would happen if a payment platform were compromised or if a rogue operator obtained credentials. The financial impact of a single compromised payment run can be material (GBP 50m to GBP 500m for a large corporate), but the probability is still perceived as low, which keeps preventive investment low.

Suggested Next Steps

• Conduct a real-time payment flow audit: map every connection between your corporate payment systems and your banks' APIs. Identify where credentials are stored, who has access and what controls detect unauthorised API usage. If you lack real-time visibility into platform-initiated payments, this is a critical gap.

• Implement a secondary authorization control for standing order changes and new payee creation within your payment platform. Do not rely solely on the platform's internal controls; require notification to your finance team and a compliance check before changes are live.

• Engage your payment platform provider on fraud detection capability. Ask whether they monitor for API credential theft, unusual payee creation patterns, or standing order modifications. If they do not, ask why and consider whether an alternative provider with stronger monitoring is justified.

• Work with your banks to establish a real-time exception notification protocol for unusual institutional payment activity. This should include anomalies that do not trigger traditional fraud rules but deviate from your normal payment behaviour.

Sources: Payment Services Regulation 2 (UK legislation), EBA Guidelines on payment initiation services, FCA APP Reimbursement Guidance, TrustSphere Risk Index, April 2026.

Companion vendor assessment: today's TrustSphere Risk Index post assesses Featurespace against this problem. Read it at www.trustsphere.ai

TrustSphere helps financial institutions design and deploy intelligent fraud and financial crime detection solutions. Visit www.trustsphere.ai