A cross-border payment reaches you with the originator shown only as a customer of the sending bank. What do you do with it, and what should your own system never have sent?

The name is not metadata

A payment message is the only thing you have. You are not the sending bank, you have no relationship with the person who instructed the transfer, and you cannot see their account history. Everything your screening engine and your monitoring rules can reason about arrived in that message. So when the originator field says something like "one of our clients", the control you thought you had is not degraded, it is absent: you cannot screen a name you do not hold, you cannot judge whether a corridor and a counterparty combination is plausible, and you cannot answer the question an investigator will ask a year later about who sent this money.

That is why the international standard treats the information travelling with a transfer as a requirement in its own right rather than as a formatting nicety. FATF Recommendation 16 — the wire transfer recommendation, often called the travel rule — obliges the ordering institution to obtain and transmit originator and beneficiary information with the transfer, obliges intermediaries to pass it along unaltered, and obliges the receiving institution to have procedures for detecting transfers where it is missing and for deciding what to do about them. The clause an interviewer is listening for is the last one: the receiving bank has an obligation, not an excuse.

What you do with the one in front of you

The payment stops before the beneficiary is credited. Once you have paid it away your leverage is gone, and clawing back a credit the customer has already spent is a different and worse conversation. So the message goes to a hold status that is visibly distinct from "under investigation for suspicion", because those are different things and conflating them contaminates both your suspicion statistics and your audit trail.

You then send a request for information to the sending institution, and the shape of that request matters. Asking "please confirm the originator" invites an answer that is a bare name, which gets you past a field-completeness check while leaving you unable to screen with any confidence. Ask for what the standard expects the sender to have held all along: the originator's name, the account number or a unique transaction reference, and an address or another identifier such as a national identity number or date and place of birth. When it arrives you screen it, and you screen it against the list version current at that moment rather than resting on the earlier pass over an empty field.

Three outcomes follow. If the information arrives and is clean you release, and you record why the delay happened, because that record is what makes the pattern visible later. If it does not arrive, or arrives self-contradictory, you reject the payment and return the funds towards the sender rather than paying it on to your customer with a hole in it. And if it arrives and is troubling — a designated party, an implausible relationship, a beneficiary with no reason to receive this — the incomplete field stops being the issue and you are into a suspicion assessment with its own reporting and disclosure constraints.

Serial payments and cover payments

Candidates who have only seen domestic rails miss why this happens at all, and the answer is in how cross-border payments are structured. In a serial payment the customer transfer itself is passed along the chain of correspondents, so every institution that touches it sees the debtor and the creditor. In a cover payment the customer transfer goes directly from the sending bank to the beneficiary's bank, while a separate bank-to-bank instruction moves the money between their correspondents to cover it.

sequenceDiagram
  participant S as Sending bank
  participant SC as Sender correspondent
  participant BC as Beneficiary correspondent
  participant B as Beneficiary bank
  S->>B: Customer transfer with debtor and creditor
  S->>SC: Cover instruction bank to bank
  SC->>BC: Funds movement
  BC->>B: Credit to beneficiary bank account

The gap worth looking at is the middle leg: the correspondents move money on an instruction that historically carried no customer detail at all, so the institutions in the settlement path were screening a bank name while the underlying parties passed unexamined. That is why the cover instruction acquired a variant designed to carry the underlying customer information, and why the industry's answer to cover payments was to make the middle leg carry names rather than to abolish the structure.

Removing information on the way out is a graver failure

The second half of the question is the half candidates skip. Your own outbound path is a place where fields disappear, usually without anyone intending it. A mapping between an internal format and the scheme message truncates a name at a shorter field length. A migration from an unstructured message to a structured one flattens a separate address block into a free-text line and loses whatever did not fit. A retry re-sends from a partially populated record. A helpful transformation strips characters an old system could not handle. None of these looks like a compliance decision when it is written, and every one of them arrives at the receiving bank as exactly the message you are complaining about.

They are worth catching for a reason beyond symmetry. Deliberately removing originator information so that a payment passes another institution's filters has been treated by authorities as evasion in its own right and prosecuted as such. That history is why "we did not mean to drop it" is a weak position, and why the control has to be preventive: validate the outbound message for required-field completeness before it leaves, alert on truncation rather than performing it silently, and reconcile the fields you sent against the fields you held so that a mapping regression is detectable rather than theoretical.

Where this becomes a relationship decision rather than a queue

One incomplete payment is an operational event. A correspondent that sends you incomplete payments routinely is a due-diligence finding, and the mistake most organisations make is to hire enough people to work the repair queue and thereby delete the signal. The counterparty's incompleteness rate belongs in its periodic review alongside its own programme, the corridors it serves, and whether it offers accounts to other institutions sitting behind your line of sight. The available responses escalate: raise it with them, restrict which payment types you will accept, require serial rather than cover routing, and ultimately exit the relationship. Each is a commercial decision, but it should be one your monitoring forces onto the table with a number attached, rather than one that never gets made because a repair team has quietly made the problem invisible.

You cannot screen a name you were not sent, so an incomplete payment is a stopped payment rather than a repaired one — and the same discipline has to point inwards, because the corridor you are complaining about is somebody else's view of your outbound mapping.