You asked
No — most compliance checks stop at one name: the beneficiary on the invoice, or the counterparty someone typed into a form. An ISO 20022 payment message (pacs.008, pain.001) structurally carries up to six distinct parties: the sender's bank, its correspondent (the ordering institution), the paying customer, one or more intermediary banks routing the payment, the beneficiary's bank, and the beneficiary. Screening only the name on the invoice checks one of six. The message also carries its own structural signal: whether it actually conforms to the official ISO 20022 schema for its declared type and version — a malformed message is a review trigger on its own, independent of who's named in it.
Six parties, not one
The sender bank sent the payment. The ordering institution is the sender's correspondent or agent bank acting on its behalf. The ordering customer is the actual payer. The intermediary is one or more additional banks the payment routes through before it reaches the beneficiary's bank. The beneficiary bank receives the payment. The beneficiary is the actual payee. All six are distinct, named fields in the message schema, not a guess.
A check built around "the counterparty" usually means whichever name appears on the invoice or the wire form — which maps, at most, to the ordering customer and the beneficiary. It structurally never reaches the banks in between, because those banks were never on anyone's invoice to begin with.
Why the intermediary is the one that gets missed
A direct payment, where the sender's bank is already a correspondent of the beneficiary's bank, needs no intermediary. Cross-border and cross-currency payments often aren't that simple — they route through one or more intermediary banks (IntrmyAgt1, IntrmyAgt2, IntrmyAgt3 in the message schema) that neither party chose or typed anywhere. They're a routing artifact of the correspondent banking network, not a line item on an invoice.
That's exactly where the real risk sits: routing a payment through a bank that isn't obviously connected to a sanctioned counterparty, precisely because nobody checks the intermediary hop on its own. Screening every role individually — not just the two human names — closes that specific gap.
The message itself is evidence, not just its content
The platform validates the actual XML against the official ISO 20022 schema for its declared message type and version — the reference schemas are pacs.008.001.12/13/14 for interbank credit transfers and pain.001.001.11/12/13 for customer credit transfer initiation. If the message doesn't conform to its own declared schema, that's flagged for review regardless of whether every named party screens clean. A malformed or non-conformant message is an anomaly worth a human look, independent of the name-matching question entirely.
One pass extracts all six roles by their position in the schema, screens each individually, and returns the structural-validity verdict alongside — rather than someone manually reading raw XML and hoping they didn't miss a role buried three tags deep.
What a payment screening result actually needs to cover
- Six roles, not one: sender bank, ordering institution, ordering customer, intermediary, beneficiary bank, beneficiary — each screened individually
- The intermediary bank is the role most manual checks skip entirely — it's a routing artifact, not a name on anyone's invoice
- Structural conformance to the ISO 20022 schema (message type and version) is its own review signal, independent of name matches
- A screening result should name which of the six roles it covered — not just confirm "the counterparty is clean"