CyphrQ

Cross-Border Payments Risk: Partner Exposure, Limits and Controls

Cross-border payment risk is partner and settlement risk as much as hacking: prefunding, open limits, maker-checker gaps, nostro breaks and sanctions.

What is the biggest risk in cross-border payments? Often it isn't the hack. It is how much of your money a partner holds, how much more it could draw, and whether one person can release a payment or raise a limit alone. Cyber attacks on payment systems succeed through those same gaps, so the business controls and the security controls are one programme.

This post is for remittance firms, payment institutions, banks and the treasury teams that use them, with the US, GCC and India corridors in mind. It is not legal or financial advice, and I don't recommend providers.

Why are cross-border payments riskier than domestic payments?

A domestic payment usually runs through one system under one regulator. A cross-border payment can pass through several banks in several countries, each holding a piece of your money for a while, before it reaches the recipient.

The central banks' payments committee at the Bank for International Settlements (the CPMI) explains why that chain attracts fraud: wholesale payments are "typically large-value, immediate and final" (CPMI, May 2018). Once a payment settles, getting it back depends on the goodwill and speed of the receiving bank.

Speed is also rising. The Financial Stability Board said in October 2025 that the global speed of wholesale payments and of remittances has improved, while the average cost of remittances "remains high", and that the G20's 2027 targets for cross-border payments are unlikely to be met on time (FSB, 9 October 2025). Faster payments are good for customers. They also shrink the window in which a bad payment can be stopped, so controls have to work before release, not after.

What are the main partner risks in cross-border payments?

Cross-border payment risk sits in four places. Each is a business decision as well as a security one.

Exposure What it means in plain words What goes wrong
Prefunding You deposit money with a payout partner or correspondent bank in advance, so payouts can be instant If the partner fails, freezes funds or is defrauded, your prefunded balance is at risk
Open and unused limits A credit or payment limit you or a partner granted that nobody is using today An unused limit is still headroom. An attacker or insider can draw it in one session
Missing maker-checker One person can both create and approve a payment, or change a limit or beneficiary alone One compromised account, or one dishonest employee, is enough to move money
Reconciliation gaps Your record of your account at a correspondent (your nostro account) is not matched against the bank's statement often enough Fraudulent or failed payments sit unnoticed until the next monthly match

On top of these sit sanctions and anti-money-laundering (AML) duties. Every party in the chain screens names and checks unusual activity. A gap at a partner can freeze your funds or put your licence in question, even if your own controls held.

What happened in the Bangladesh Bank heist?

The best documented example is the 2016 theft from Bangladesh Bank, where the Federal Reserve Bank of New York stopped most of the attempt.

The US cybersecurity agency CISA attributes it to a North Korean group it calls the BeagleBoyz. Its advisory says the group "stole $81 million from the Bank of Bangladesh in 2016", and that the New York Fed stopped the rest of an attempted $1 billion theft after it detected anomalies in the transfer instructions (CISA AA20-239A, FASTCash 2.0). On 6 September 2018 the US Department of Justice announced charges against a North Korean programmer, Park Jin Hyok, covering this and other attacks (DOJ announcement). I could not open the DOJ complaint itself, so I take no figures from it.

Set against the four exposures above, the case shows three things:

  • The instructions went to a partner. The transfer instructions went to a bank in another country, the New York Fed, so checking them before release was shared between two institutions.
  • The attacker used the bank's own channel. CISA describes the group gaining access to a bank's terminal on Swift (the interbank messaging network, formerly styled SWIFT), monitoring it, sending fraudulent payment messages and trying to hide that activity. Messages that come from a genuine terminal look genuine.
  • The receiving side's checks worked best. What stopped most of the attempt was the New York Fed spotting anomalies. A sender-side check on value, timing and beneficiary pattern is the control you own.

The same group did not stop there. CISA says the BeagleBoyz "have attempted to steal nearly $2 billion since at least 2015, according to public estimates", and lists financial institutions in 38 countries it likely targeted from 2015 to 2020, including India, Kuwait, Pakistan, the Philippines and Bangladesh (CISA AA20-239A). For GCC and Indian remittance corridors, that is not a distant story.

Which controls reduce cross-border payment fraud?

The CPMI's 2018 strategy on wholesale payments fraud lists tools that banks and payment systems can use. They read like a partner-risk checklist (CPMI, Annex 1):

  1. Participant-defined payment limits, for example processing payments only when they go to a known correspondent, within business hours, under an amount limit.
  2. Payment screening against parameters you set yourself.
  3. Detection of unusual payment patterns in timing, value, volume or location.
  4. Frequent and timely (intraday) reconciliations.

Add the business-side controls:

  • Cap and monitor prefunding. Set a maximum prefunded balance per partner, tied to that partner's credit standing, and review it when volumes change.
  • Close unused limits. Review every open limit quarterly. If nobody has used it in 90 days, ask why it still exists.
  • Four-eyes on release and on standing data. Maker-checker, also called four-eyes, means a second person approves what the first person created. Apply it to payment release, limit increases and new or changed beneficiaries. The CPMI names "requesting an approval after a payment initiation" and segregation of duties as examples of process controls.
  • Reconcile nostro accounts daily or intraday, and treat an unexplained break as an incident, not a back-office chore.
  • Know your partner's controls. Ask payout partners for evidence of their security, sanctions screening and incident process, the same way you would assess any critical supplier. The third-party risk management guide covers tiering and contract terms.

Payment fraud that targets people rather than systems, such as fake supplier invoices or a deepfake CEO on a call, also ends in a cross-border transfer. Deepfake scams covers that side, and UK APP fraud reimbursement rules covers who pays when a customer is tricked.

Going deeper: for security and IT teams

This section is for payment operations, security architecture and IT audit teams that run or connect to Swift, a payment switch or a partner API.

Threat model. CISA's advisory describes two patterns at the level of public guidance. In Swift fraud, an attacker gains access to a bank's Swift terminal, watches normal activity, sends fraudulent payment messages and tries to hide them, using unwitting banks, including US banks, as pass-throughs. In the FASTCash ATM cash-out scheme, malware on the bank's payment switch server, which processes ISO 8583 card transaction messages, intercepts requests for chosen accounts and returns fake approvals, so ATMs pay out and the issuer's core system never sees the transaction (CISA AA20-239A). In both, the attacker needs privileged access inside the payment environment. What they get is money that settles before anyone reconciles.

Controls with specifics, from CISA's mitigations:

  • Verify compliance with the US FFIEC examination handbooks, and with industry standards for critical systems, including PCI standards and the Swift Customer Security Controls Framework (CSCF). Check the current CSCF version and your attestation status with Swift.
  • Require multi-factor authentication for anyone accessing the switch application server.
  • Isolate payment infrastructure, and block internet hosts from reaching the private network that supports the switch.
  • Segregate network enclaves with firewalls and access control lists.
  • Secure links to payment engines with certificate-based authentication such as mutual TLS.
  • Log transactions, audit the logs routinely, and baseline expected software, users and transaction patterns.

Independent confirmation of what left the building. The most useful detective control is a comparison the attacker cannot edit: payment messages actually sent on the network, matched against payments approved in the core banking or treasury system, from a separate data feed. Run it intraday. A message with no matching approved payment is a priority alert.

Alert rules worth building:

  • Payments outside the corridor's normal business hours, or on a local holiday at either end.
  • First payment to a new beneficiary or a new correspondent, especially above your median value.
  • Several payments just under an approval threshold in a short period.
  • A limit increase or beneficiary change followed by a payment within hours.
  • Any change to the four-eyes configuration itself, which should need its own second approval.

Respond fast, without promising recall. The CPMI asks operators and participants to respond to suspected fraud "in a timely manner", including requests to act on a suspect payment instruction, while noting that such procedures should not alter the finality of a payment that has already settled (CPMI, Element 5). Keep a current contact list for every correspondent's fraud desk, and rehearse the cancellation request.

Partner exposure as a number. Report one figure per partner to treasury and risk every day: prefunded balance, plus unused limits, plus payments in flight. That is your loss if that partner fails or is compromised today. If that number would hurt, the controls above are not optional.

Questions for your partners and your auditors:

  • Who can release a payment, change a limit or add a beneficiary, and does each need a second approver?
  • How often are nostro accounts reconciled, and who signs off unexplained breaks?
  • Is the payment environment segregated, with MFA on every admin and operator account?
  • When did the partner last attest against its payment network's security framework, and can we see the result?
  • How fast will the partner tell us about an incident that affects our funds?

Key takeaways

  • Cross-border payment risk is partner and settlement risk as much as cyber risk: prefunding, open limits, maker-checker and reconciliation.
  • CISA attributes the 2016 theft of $81 million from Bangladesh Bank to North Korea's BeagleBoyz. The New York Fed stopped the rest of an attempted $1 billion after spotting anomalies.
  • CISA lists India and Kuwait among the countries the group likely targeted between 2015 and 2020.
  • The CPMI's toolset is practical: payment limits by correspondent and hours, screening, unusual-pattern detection and intraday reconciliation.
  • Track one number per partner every day: prefunding plus unused limits plus payments in flight.

A partner-risk checklist for payment teams

  1. List every payout partner and correspondent, with the prefunded balance and open limits for each.
  2. Close limits nobody uses, and cap prefunding per partner.
  3. Turn on four-eyes for payment release, limit changes and beneficiary changes, and log every approval.
  4. Reconcile nostro accounts at least daily, and treat breaks as incidents.
  5. Compare sent payment messages with approved payments from an independent feed.
  6. Check your Swift CSCF attestation and your partners' evidence each year.
  7. Rehearse a fraud cancellation request with your main correspondents.

Sources