Request for Information and Investigation Messages

A payment can be technically valid, successfully transmitted and still leave a bank with a question that matters. The purpose in the remittance field may be vague. A correspondent may see a transaction pattern it cannot explain from the payment message alone. A beneficiary bank may be unable to reconcile funds. A sanctions or compliance reviewer may need more information before deciding whether an alert can be closed. An investigator may understand the customer but not the relationship between the originator, beneficiary and an apparent third party. In each of these situations the missing element is not necessarily another screening rule. It is information.

A request for information, or RFI, is a controlled way of asking another party for information needed to understand a transaction, customer relationship or payment event. In correspondent banking, an RFI often travels from a correspondent bank to its respondent bank because the correspondent can see the payment but does not hold the underlying customer's full KYC record. In a payment-operations context, an investigation message can also ask why funds have not arrived, why they cannot be applied, or what information is needed to continue processing. In a financial-crime context, the question may concern source of funds, transaction purpose, customer profile, counterparty relationship, goods or services, beneficial ownership, geographic context or another fact relevant to an AML, sanctions or broader compliance review.

The important point is that these are related but not identical processes. A transaction-monitoring RFI described by the Wolfsberg Group is not the same thing as every operational payment investigation. A sanctions enquiry can have different urgency and legal consequences from a retrospective AML enquiry. A law-enforcement request has a different legal basis and governance path again. Swift's ISO 20022 investigation messages provide structured network messages for defined exceptions-and-investigations use cases, but they do not replace a bank's AML policy, privacy analysis, suspicious-activity decisioning or local legal obligations.

A useful mental model is therefore: question, evidence, response, judgement, action. The bank should know why it is asking, what evidence would answer the question, who is permitted to provide that evidence, how the response will be assessed, and what happens if the answer is complete, incomplete, contradictory or absent. An RFI that asks for everything “just in case” is poor control design. A response that supplies documents without answering the actual question is equally weak.

The three investigation worlds a bank must keep separate

The phrase “payment investigation” is used loosely in banks, which creates avoidable confusion. The first discipline is to identify which problem is being solved.

The first world is operational exceptions and investigations. A payment has not arrived, cannot be applied, contains information that prevents processing, or needs clarification. These cases may be handled by payment operations, correspondent banking operations or a central investigations team. The primary objective is to resolve the payment event accurately and quickly. Some cases have a financial-crime dimension, but many do not.

The second world is financial-crime information gathering. A monitoring alert, customer review, correspondent-bank review or compliance escalation raises a risk question. The bank needs context that is not available internally, so it asks a respondent bank, another permitted financial institution, a customer or another authorised source. The objective is not simply to repair the payment; it is to determine whether the observed activity can be reasonably understood, whether suspicion remains, whether restrictions are needed, or whether the relationship requires escalation.

The third world is formal authority or regulatory information requests. These include subpoenas, production orders, FIU requests, law-enforcement enquiries and regulatory demands. They are governed by the applicable law and the bank's legal and regulatory-response process. They should not be treated as an ordinary correspondent-bank RFI merely because both involve information. Different confidentiality, disclosure, preservation, deadline and escalation rules can apply.

Banks sometimes create one generic case type for all three. That looks efficient at first but causes problems later. The mandatory data differs. The people authorised to view the case differ. The response clock differs. The permitted information-sharing basis differs. The legal hold or tipping-off implications can differ. The outcome vocabulary differs. A sound case model can share common components while preserving the distinctions.

Why RFIs matter in correspondent banking

Correspondent banking creates an information asymmetry. A correspondent bank may process transactions for customers of its respondent bank without holding those underlying customers as its own direct customers. The correspondent sees payment data, account activity and patterns flowing through the relationship, while the respondent normally holds the deeper KYC and account context for the underlying customer.

The Wolfsberg Group's 2022 Transaction Monitoring Request for Information Best Practice Guidance explains why RFIs can be valuable in this setting. A correspondent that identifies unusual or potentially suspicious activity may need information such as the underlying customer's KYC background, the purpose of the account, the purpose of the transaction, the nature of the observed activity, source of funds, goods or services, beneficial ownership, counterparty details or the relationship between parties. Used well, an RFI can help the correspondent determine whether an alert has a reasonable explanation, whether suspicion remains, whether further investigation is needed or whether a risk-mitigating action is appropriate.

An RFI is not a substitute for the correspondent's own risk-based due diligence on the respondent relationship. Nor does it automatically turn the correspondent into the KYC owner for every underlying customer. Wolfsberg explicitly notes that there is no general expectation that a correspondent conduct due diligence on all customers of the respondent, often described as “know your customer's customer” or KYCC. The correspondent needs enough information to understand the risks it sees and meet its own obligations, but control design should avoid creating an impossible universal-KYCC model.

The respondent also learns from the RFI. A question from a correspondent may expose a pattern the respondent had not previously detected, reveal how activity looks when viewed across a different part of the payment chain, or identify a weakness in the respondent's own customer data. A mature respondent therefore does not treat every incoming RFI as administrative correspondence. It considers whether the request itself is intelligence that should trigger local review, KYC refresh, monitoring feedback, relationship-manager action or another control response.

This two-way value is important. The issuing bank sees only part of the story; the respondent sees another part. An effective RFI joins those views without pretending that either bank has complete information.

Start with the investigative question, not the questionnaire

Poor RFIs often begin with a template containing twenty or thirty standard questions. The investigator selects most of them because the case looks risky. The respondent then receives a broad demand for KYC, source of wealth, source of funds, ownership, invoices, contracts, counterparty details and an explanation of activity. That may produce hundreds of pages of material while leaving the original risk question unanswered.

A better process starts by writing the investigative question in one sentence. For example: “Why did a recently established import company send six payments totalling EUR 1.8 million to an electronics wholesaler in a country not present in its expected customer profile, and are the goods and counterparties consistent with the customer's stated business?” That question identifies the pattern, the uncertainty and the facts likely to resolve it.

The bank can then request only information material to that question. It may need the customer's business activity, relationship duration, expected payment corridors, purpose of the six payments, description of goods, commercial relationship with the beneficiary, source of funds and supporting invoice or contract. It may not need a full copy of every KYC document or unrelated account history.

Wolfsberg recommends that the correspondent review its own information and public-domain sources before issuing an RFI, ask only information pertinent to the financial-crime concern, explain the rationale briefly, and write clear questions that can be understood by the recipient. Those principles reduce unnecessary data sharing and shorten the response cycle.

This also matters for privacy and data minimisation. Asking for information because it might be useful later is not the same as having a defined purpose for collecting it. The lawful basis and permitted scope depend on jurisdiction and the relationship between the institutions. A global bank should maintain legal and privacy guidance that tells investigators what may be requested, what may be disclosed, how sensitive information is protected, and where additional approval is needed.

What a good RFI contains

A useful RFI makes it easy for the recipient to understand which transaction or pattern is in scope and what answer is expected. At minimum, the case needs an unambiguous reference to the underlying transaction or relationship, the requesting institution, the recipient institution, the questions, the response due date or service expectation, and a secure response path.

For a payment investigation, correlation identifiers are critical. The UETR can connect the enquiry to the underlying cross-border payment where applicable. Other references such as the original instruction identification, transaction identification, end-to-end identification, bank reference, account reference or case identification may be needed depending on the rail and systems involved. The bank should preserve the original identifiers rather than create a new local reference and lose the link to the payment.

The RFI should also state the scope. If the concern is a pattern of twelve payments, naming only one sample payment can cause the respondent to answer narrowly. If the question concerns a specific party, the bank should distinguish that party from similarly named parties. If it concerns a date range, the range should be explicit. If it concerns a sanctions or compliance issue, the bank should be careful not to disclose protected information or investigative hypotheses that local law or policy forbids sharing.

A well-designed structured message or case interface can capture these components separately: case identifier, underlying payment identifier, request category, reason, question, requested evidence, priority, due date, requester, recipient, contact channel, confidentiality classification and status. Free text remains useful, but it should explain the question rather than carry every data element in an unstructured paragraph.

What a good response contains

A good response answers the question directly and distinguishes fact from assessment. “Customer is known to us” is not an explanation of a payment. “Transaction is in line with profile” is stronger only if the response provides enough context to show why. A high-quality answer might state that the customer has banked with the respondent for seven years, imports industrial sensors, normally pays suppliers in Germany and Singapore, added the beneficiary after entering a new distribution agreement, funded the payments from documented sales receipts, and supplied invoices corresponding to the six transactions. The respondent can then state whether its own review identified concerns, subject to what local law permits it to disclose.

Evidence should have provenance. If the respondent says the payment was for medical equipment, was that description already present in KYC or payment records, provided by the customer after the RFI, taken from an invoice, or inferred by an analyst? Those sources have different evidential weight. A case system should preserve the distinction.

Attachments also need control. Invoices, contracts, identification documents and customer correspondence can contain personal or commercially sensitive information. The receiving bank should know the document source, date received, relevant transaction, integrity status where applicable and access classification. Documents should not be copied casually into email chains or local drives outside the case record.

An incomplete response should not be treated as a binary failure. The bank should assess which questions remain unanswered and whether the missing information is material to the decision. Wolfsberg notes that broader information may sometimes answer the investigative concern even if the respondent did not answer every question in the exact requested format. Conversely, a beautifully formatted response can still be inadequate if it avoids the central issue.

Response quality is a decision, not a checkbox

Banks benefit from a response-quality gate that asks several practical questions.

First, identity and scope: does the response clearly relate to the correct customer, counterparty, account and transaction set? A response about a company with the same name in another branch is worse than no response because it can create false comfort.

Second, coverage: are the material questions answered? If the RFI asked for the relationship between originator and beneficiary and the response provides only the customer's incorporation documents, the central uncertainty remains.

Third, evidence: are important assertions supported by information the respondent could reasonably know or obtain? A statement about goods may be supported by invoice details; a statement about source of funds may rely on account history and documented revenue; an ownership statement should reflect current KYC or reliable corporate records.

Fourth, consistency: does the response fit the payment data, customer profile, transaction pattern and other known facts? If the respondent says the customer is a domestic retailer but the account shows repeated high-value international trade payments, the discrepancy needs resolution.

Fifth, timeliness and freshness: was the information current enough to support the decision? Old KYC can be useful history but may not explain a new business line or recent ownership change.

Sixth, legal usability: may the receiving team use and retain the information for the intended purpose under the applicable legal, secrecy, privacy and contractual framework? This is not a matter for the investigator to improvise case by case. The bank should have an approved information-sharing framework.

Timelines: reasonable does not mean arbitrary

There is no single global RFI response deadline for every correspondent-banking financial-crime enquiry. Wolfsberg's 2022 guidance says that correspondent expectations commonly range from roughly 10 to 30 business days, while stressing that this is indicative and may vary with complexity, age of transactions, regulatory expectations and information-sharing constraints. That range should not be converted into a universal legal SLA.

The right operating model uses risk and purpose. A retrospective transaction-monitoring enquiry about a six-month-old pattern may reasonably allow more time than a question preventing a live payment from being processed. A potential sanctions issue may require immediate escalation under applicable law and cannot be parked behind a standard twenty-day RFI queue. A high-value customer payment approaching a market cut-off has a different customer-impact clock from a periodic correspondent review.

The issuing bank should state the expected response date. The respondent should acknowledge the request promptly, assign ownership and communicate when more time is needed where permitted. The case should distinguish response due date from regulatory or legal decision deadline. An RFI deadline must never silently override a reporting deadline, freeze obligation, return deadline or scheme cut-off.

Ageing should be measured from meaningful events: created, sent, acknowledged, response received, follow-up issued, final response received, decision made and case closed. One “case age” number cannot tell management whether the delay sits with the issuing analyst, respondent bank, customer outreach, legal review or internal approval.

What to do when the response never comes

No response is itself information, but it is not automatic proof of money laundering. The recipient may have sent the request to the wrong contact, the respondent may be constrained by law, records may be archived, the underlying customer may be downstream from the respondent, or the institution may have weak controls. The issuing bank should distinguish operational failure from risk-significant non-cooperation.

Wolfsberg recommends risk-based handling of insufficient and non-responses, with governance around timeliness and response quality. Repeated poor responses can affect the correspondent's view of the respondent relationship and may lead to enhanced review, restrictions or other risk-mitigating actions. In some jurisdictions and circumstances, inadequate information can contribute to a suspicious-activity reporting decision. The chapter deliberately avoids stating that a missing RFI response automatically requires a SAR or STR; that determination is jurisdiction-specific and fact-dependent.

At the transaction level, the bank needs an explicit decision path. Can the case be closed using other reliable information? Is a targeted follow-up justified? Does the activity remain unexplained enough to escalate to an AML investigator? Does the bank need to restrict a particular customer, payment type or corridor under its risk appetite? Is there a separate sanctions or legal reason to hold or reject the payment? These questions should be answered by policy and case facts, not by queue-age automation alone.

At the relationship level, management information should identify respondents that repeatedly miss service expectations, provide generic answers or fail to address material questions. A pattern across hundreds of RFIs may be more important than one late reply.

ISO 20022 investigation messages: what changed

Payment investigations historically relied heavily on free-format or semi-structured messages and manual bilateral workflows. That made correlation difficult. One bank might send a narrative request, another might reply with a local reference, and operations staff could spend time reconstructing which response belonged to which payment. Structured ISO 20022 messages and orchestrated case management are intended to reduce that friction.

Swift's current Exceptions and Investigations material identifies camt.110 as the Investigation Request and camt.111 as the Investigation Response for E&I. Swift's Case Management service uses Case Orchestrator to exchange these messages, with the UETR and case-management features supporting routing, pre-population, tracking and automation. The messages are not simply “new MT199s”. Their value comes from structured fields, common investigation types and an orchestrated case lifecycle.

Swift currently distinguishes E&I from payment cancellation. A cancellation request uses camt.056, and the response to that cancellation uses camt.029. A bank should therefore not use “camt.110” as a generic word for every payment problem. The message choice follows the business process.

Swift has also published specific investigation types supported by Case Management. These include creditor claims non-receipt, cover creditor claims non-receipt, request for information where a payment is unable to execute, unable-to-apply scenarios, and compliance or sanctions RFI use cases in the evolving service. Product teams should use the applicable current usage guidelines and rulebook rather than invent internal subtypes that cannot be mapped consistently to the external service.

The September 2026 migration position matters

E&I migration dates have changed over time, so training material must use the latest position rather than an old project plan. Earlier Swift migration material planned mandatory receipt of camt.110 with in-flow translation and an embedded MT 199 for November 2026. Swift's later public announcement, updated 21 September 2026, schedules the deferred SR2026 release, explicitly including exceptions and investigations messages, for 12 June 2027. Banks must reconcile the detailed Case Management rollout with the current Swift customer guidance rather than present the superseded November date as an unconditional obligation. Swift states that camt.110 and camt.111 exchange through Case Orchestrator is already available to Case Management participants.

Swift's previously published roadmap targeted November 2027 for the fully structured Case Management model using camt.110 and camt.111, removal of the legacy formatted MT E&I messages, and discontinuation of free-format MT n99 for E&I purposes. It also targeted November 2027 for mandatory Stop and Recall payment cancellations. Following the September 2026 release changes, banks must check the latest Swift customer guidance for those service-specific milestones and transition rules; the public release announcement alone does not confirm that every later milestone remains unchanged.

That timeline is a Swift network/service requirement, not a global legal rule for every domestic payment system. A bank implementing local real-time payments, ACH investigations or card disputes may use entirely different messages and deadlines. The architectural lesson is to separate the business concept of an investigation from the transport and message profile used by each rail.

The planned in-flow model creates a transitional design challenge regardless of the final rollout date. A bank may receive a structured camt.110 carrying an embedded MT 199 while its internal back office still responds through a legacy workflow. The control must preserve the structured case reference and underlying payment linkage even if the human team sees only the translated content. If the translation path loses fields or the bank creates a new unrelated local case, the industry benefit of end-to-end correlation is weakened.

Investigation message is not a financial-crime conclusion

Receiving a compliance or sanctions RFI does not mean the customer is guilty, sanctioned or suspicious. It means another institution needs information to resolve a question. Likewise, sending an RFI does not outsource the issuing bank's decision. The issuing bank must assess the response and the totality of available evidence under its own obligations.

This distinction protects customers from inappropriate action. A beneficiary bank may receive an RFI because an intermediary lacks context that the beneficiary bank already has. The beneficiary bank should answer the permitted question accurately, not automatically freeze the customer's account. Conversely, a respondent should not assume that providing an invoice ends the matter if the invoice contradicts transaction behaviour or appears unreliable.

In sanctions operations, the urgency can be higher. A bank may need information to determine whether a payment involves a designated party, prohibited geography, restricted ownership or another applicable restriction. The legal action—release, reject, block, freeze, report or obtain a licence—depends on the relevant sanctions regime and jurisdiction. An RFI can support fact-finding, but it does not change the legal test.

Do not confuse an RFI with a payment repair

A payment repair corrects or completes information needed for processing. An RFI seeks information to resolve an uncertainty. Sometimes the two interact. If a payment cannot execute because required beneficiary information is missing, the receiving bank may request that information and then update the payment through the permitted repair process. But a financial-crime RFI sent after transaction monitoring has identified unusual activity is not a repair instruction.

This distinction matters for audit trails. When a bank changes the payment message, the system should record what was changed, by whom, under what authority and whether controls were re-run. When a bank receives contextual information for an AML case, that information should normally enrich the case record rather than silently overwrite the original payment data. Investigators need to know what the payment contained at execution time and what information arrived later.

A common failure is “helpful” operations staff adding customer-provided wording into payment fields after a compliance question. That can make the final message appear as though the information was present originally. The system should preserve the original event and the subsequent evidence separately.

FATF Recommendation 16: transparency, not one universal RFI procedure

FATF Recommendation 16 is the global standard for information accompanying wire transfers and payment transparency. FATF revised Recommendation 16 in June 2025 and consulted in June 2026 on implementation guidance for the strengthened standard. FATF has stated that countries are expected to be ready to implement the strengthened requirements by the end of 2030.

Recommendation 16 is relevant to RFIs because missing, incomplete or inconsistent payment-party information can prevent institutions from understanding who is sending and receiving value. But FATF does not define one global bank-to-bank RFI message, one universal SLA or one mandatory questionnaire. Countries and regions implement the standard through their own legal frameworks, while payment networks define technical message rules.

This separation should be explicit in requirements. “FATF requires camt.110” would be wrong. camt.110 is an ISO 20022 investigation message used by Swift Case Management. “FATF requires every RFI response within 20 days” would also be wrong. The response expectation depends on the legal and relationship context. The correct requirement chain is global standard, jurisdictional implementation, network or scheme rule, bank policy and case facts.

The EU example: missing payment information has a defined legal framework

The European Union illustrates why local legal scoping matters. Regulation (EU) 2023/1113 sets information requirements for transfers of funds and certain crypto-assets. The EBA's Travel Rule Guidelines, applicable from 30 December 2024, explain steps that payment service providers and intermediary providers should take to detect missing or incomplete information and procedures for managing transfers that lack required information.

That framework may lead a provider to request missing information, reject or suspend a transfer, or take other actions depending on the facts and the regulation. Those are EU requirements. They should not be presented as though the same articles apply to a bank in Singapore, Canada or South Africa. A global payment hub can support a common data model and common workflow, but its rule engine must know which legal entity, corridor, payment type and jurisdictional obligations apply.

The EU rules also demonstrate that “missing information” is not purely technical. The provider has to identify whether required information is absent or incomplete and apply appropriate procedures. That can require data-quality controls, counterparty communication, repeat-failure monitoring and escalation beyond one payment.

Information-sharing limits, confidentiality and tipping-off

An RFI process sits at the boundary between useful information sharing and protected information. Banks need a legal framework for both outgoing requests and incoming responses.

The respondent may hold personal data, commercially sensitive documents, KYC records and internal risk assessments. Local privacy, bank-secrecy, confidentiality and data-localisation rules can limit what may be disclosed across borders. A well-designed response does not simply say “privacy prevents us from answering”. It identifies what can be shared, what cannot, the reason for the limitation where disclosure of that reason is permitted, and whether an alternative confirmation can answer the risk question.

Suspicious-activity reporting creates another boundary. Many jurisdictions restrict disclosure that would reveal that a SAR or STR has been filed or that a related protected investigation is underway. The exact prohibition differs by law. The bank should therefore have approved wording and escalation procedures so RFI teams do not accidentally disclose protected information. An analyst should never invent a euphemism intended to hint at a SAR filing.

The United States provides a separate example of authorised information sharing through FinCEN's Section 314(b) programme. FinCEN describes 314(b) as voluntary information sharing among eligible registered financial institutions and associations for identifying possible money laundering, terrorist activity and related suspected fraud within the scope of the rule. That safe-harbour framework is useful, but it is not the legal basis for every international correspondent RFI. A multinational bank must avoid importing a US-specific sharing rule into other jurisdictions.

From alert to RFI to case outcome

The most useful way to design this process is as one evidence chain rather than separate queues.

A transaction-monitoring alert identifies a pattern. The investigator first reviews internal data: customer profile, related accounts, prior alerts, previous RFIs, payment messages, sanctions results, device or channel data where relevant, public information and existing documents. If the concern can be resolved internally, no external RFI is needed.

If a material gap remains, the investigator records the question and selects the institution or party that can reasonably answer it. The RFI is generated with the underlying transaction references and only the required questions. The case status changes to awaiting external information, but ownership remains with the issuing bank.

When the response arrives, the case system links it automatically or through controlled reconciliation. The investigator assesses completeness, provenance and consistency. A credible response may explain the activity and support closure. A partial response may require a targeted follow-up. A contradiction can increase concern. No response can lead to escalation depending on risk and relationship history.

The final outcome may be alert closure with rationale, enhanced monitoring, customer review, payment restriction, respondent-relationship action, sanctions escalation, fraud referral, SAR or STR consideration, account or relationship exit, or another local-policy outcome. The RFI itself is not the outcome. It is one step in reaching an evidence-based outcome.

Systems and data touchpoints

A bank-grade implementation normally touches more systems than the case-management screen suggests. The payment hub or gateway holds the original payment message and identifiers. The transaction-monitoring platform holds the alert and pattern features. The customer master and KYC platform hold profile and ownership data. Sanctions screening may hold its own alert and list-version evidence. The case-management platform coordinates the investigation. A messaging gateway or Swift interface sends and receives the external enquiry. Document management stores evidence. Reporting platforms aggregate ageing, response quality and relationship trends.

The case model should not duplicate all source data blindly. It should preserve stable references to the source and snapshot the information needed to reconstruct the decision. If the customer's KYC record changes after the case closes, the investigator still needs to show what information was available when the decision was made. That normally requires effective dating or evidence snapshots.

Correlation is fundamental. At minimum, the bank should be able to move from the RFI to the case, from the case to the underlying payment or payment set, and from the payment back to the RFI. UETR is particularly useful for Swift cross-border payments, but local identifiers remain necessary because not every transaction has a UETR and one investigation can cover multiple transactions.

A canonical RFI object can contain: request ID, external case ID, internal case ID, requester and respondent BIC or institution identifier, underlying payment IDs, parties in scope, question category, questions, evidence requested, send channel, timestamps, due date, response ID, response status, attachment metadata, analyst decision, escalation path and closure reason. The object should also record the versions of relevant policy or rule logic used for automated decisions.

Integration design: preserve meaning across channels

During the transition from legacy messages to structured ISO 20022 investigations, banks may support GUI, API, FINplus and legacy FIN workflows simultaneously. The architecture should avoid creating four independent investigation histories.

The bank's internal case ID should remain stable regardless of external channel. If a camt.110 arrives with an embedded MT 199 and operations responds using the legacy path, the internal record should preserve both representations and the external Case Management reference. If a GUI user adds an attachment, downstream API consumers should still see the attachment metadata. If the message is re-routed to another agent, the audit trail should retain the routing history.

Translations require special care. Swift notes that MX-to-MT translation can lose or truncate data where the richer ISO 20022 content has no equivalent MT field or exceeds legacy field lengths. For camt.110, the embedded MT 199 is primarily a transition mechanism. A bank should not assume that the translated narrative contains every structured element available in the original request. If decision-critical data exists only in the structured message, the internal platform must preserve access to it.

The same principle applies to outgoing responses. Generating a free-text legacy response from a structured case can discard category, identifiers or evidence metadata. Migration testing therefore needs semantic comparison, not only proof that a message was technically sent.

Roles and decision rights

Clear role design prevents RFIs from becoming an administrative orphan.

The investigator or case owner defines the question, reviews internal evidence, assesses the response and owns the final case recommendation. The payment investigations team may manage operational E&I messages and payment-status enquiries. The correspondent-banking relationship team manages service expectations and repeated response-quality issues with respondent institutions but should not override independent financial-crime judgement for commercial reasons. KYC teams provide customer profile evidence and may trigger refreshes. Sanctions specialists determine sanctions applicability and legal action where relevant. Legal and privacy teams define sharing boundaries. Technology and data teams preserve identifiers, routing, message integrity and evidence lineage. Quality assurance tests whether cases meet the decision standard. Second-line compliance sets policy, challenges effectiveness and escalates material risk. Internal audit provides independent assurance.

Decision rights should be explicit for sensitive actions. Who can restrict payments from a respondent? Who can approve an extension to an RFI response date? Who can disclose KYC documents cross-border? Who decides that an insufficient response contributes to a SAR or STR decision? Who can close a case where the respondent did not answer? Those rights should be configured in workflow permissions where possible rather than left to informal email approval.

Management information that actually tells management something

RFI dashboards often count requests sent, requests received and average age. Those numbers are useful but insufficient. A mature bank needs to know whether the process reduces risk and where it fails.

Useful measures include the proportion resolved using internal information without an external RFI, first-response completeness, follow-up rate, median and tail response times, cases beyond risk-based SLA, respondents with repeated insufficient answers, questions most often generating clarification, percentage of cases where the RFI changed the case outcome, restrictions caused by non-response, customer-impact days, and the proportion of responses that triggered local KYC or monitoring action.

Quality should be sampled directly. A fast response that says “payment is legitimate” may score well on timeliness and poorly on usefulness. A slower response supported by customer records may be materially better. Management information should therefore combine timeliness and substantive quality.

Trend analysis can reveal upstream weaknesses. If many RFIs ask for beneficiary relationship because corporate payment channels do not capture meaningful purpose information, the right fix may be better data at initiation rather than more investigators. If a particular respondent repeatedly cannot explain downstream payments, the issue may sit in correspondent-risk management. If analysts send broad RFIs that generate large document packs and multiple follow-ups, training or templates may need redesign.

Failure modes to watch for

The first failure mode is template inflation: every case gets the same long questionnaire. This increases data, delay and frustration while reducing focus.

The second is case detachment: the RFI cannot be reliably linked to the original payment or monitoring alert. Analysts then reconstruct context manually, sometimes attaching the response to the wrong case.

The third is false closure from documentary comfort. Receiving an invoice or contract feels reassuring, so the case closes without checking whether the document actually explains the pattern, parties, amounts and business model.

The fourth is response-copying. A prior RFI response is copied into a new case without checking whether ownership, business model or transaction purpose has changed.

The fifth is translation blindness. The bank treats an embedded or translated MT narrative as equivalent to the full structured investigation message and never checks whether structured fields were lost.

The sixth is deadline confusion. A generic RFI SLA is allowed to override a faster sanctions, legal, reporting or scheme deadline.

The seventh is tipping-off risk. Investigators reveal too much about the bank's suspicion or reporting activity while trying to explain why they need information.

The eighth is relationship pressure. A commercially important respondent asks the bank to close repeated enquiries quickly, and operations weakens the evidence standard to preserve service metrics.

The ninth is orphan intelligence. The respondent answers the correspondent but fails to consider whether the RFI reveals a risk in its own customer's activity.

The tenth is no learning loop. Hundreds of similar RFIs are processed manually even though the root cause is missing payment data, poor KYC, a defective message mapping or a monitoring scenario that could be improved.

Practical mini case: an RFI that changes the investigation

Consider a European correspondent bank processing USD-equivalent cross-border payments for Respondent Bank A. Transaction monitoring identifies eight payments over six weeks from a small machinery importer, Northstar Components Ltd, to three beneficiaries in two countries. The total value is materially above Northstar's previous activity. The payment narratives say only “invoice settlement”. One beneficiary has the same address as an unrelated company seen in another alert.

The correspondent reviews its own information first. Payment data shows consistent UETRs and no missing mandatory party names. Sanctions screening has no confirmed matches. Public records show that Northstar exists and trades industrial equipment, but the correspondent does not know whether these new suppliers fit the customer's business, what goods were purchased or why the payment volume changed.

The investigator records the question: “Are the new supplier relationships and increased payment values consistent with Northstar's legitimate machinery-import business, and what explains the common beneficiary address?” The RFI to Respondent Bank A asks for relationship duration, expected business activity, reason for the increase, goods associated with the eight payments, relationship to the three beneficiaries, source of funds and an explanation of the shared address. It asks for relevant supporting evidence rather than the customer's entire KYC file.

Respondent Bank A discovers that Northstar won a new contract to supply temperature-control equipment to a domestic food producer. Two beneficiaries manufacture refrigeration components. The third beneficiary is a logistics consolidator. Invoices and a signed supply contract support the amounts. The shared address belongs to a recognised industrial export agent that provides office and documentation services to several suppliers. Account history shows that the payments were funded by staged receipts from the food-producer customer. Respondent Bank A also notices that Northstar's expected annual turnover in KYC is now outdated and initiates a KYC refresh.

The response does not simply say “no concern”. It explains the commercial chain, identifies the evidence source and acknowledges the KYC update. The correspondent verifies that the payment pattern aligns with the documents and public information. It closes the monitoring case with a clear rationale but records the new supplier corridor in its relationship analytics.

Now change one fact. Suppose the respondent cannot identify the third beneficiary, Northstar refuses to explain the relationship, and the invoices supplied for the largest payments contain inconsistent goods descriptions and duplicate numbering. The same RFI process now produces a different outcome. The correspondent escalates the case, considers additional restrictions under policy and assesses whether suspicious-activity reporting is required in its jurisdiction. The quality of the RFI process is shown not by whether cases close, but by whether different evidence produces appropriately different decisions.

What a business analyst should define

A business analyst working on RFI or E&I capability should start with business states and information ownership before writing message mappings. The requirement should define how a case is created, which identifiers are mandatory, which investigation types are supported, what data is pre-populated, what may be edited, how questions are structured, how due dates are calculated, which channels are supported, how responses are correlated and how exceptions are escalated.

Requirements should distinguish original data from later evidence. The original payment message must remain immutable as evidence even if operations repairs a subsequent transaction or the respondent supplies corrected information. The case should record the relationship between them.

The BA should define legal-entity and jurisdiction applicability. A global workflow can use one technical platform while applying different rules for privacy, retention, reporting, sanctions handling and permitted information sharing. Those rules should be configuration or policy components with owners and effective dates, not hard-coded assumptions hidden in the interface.

Non-functional requirements matter. Investigation workflows can contain sensitive personal data and documents, so access control, encryption, audit logging, retention, data residency and download restrictions should be explicit. Availability is important because a case-management outage can stop time-sensitive payments or leave incoming RFIs unacknowledged. Performance requirements should reflect volume spikes and network cut-offs rather than an average day.

Testing the whole journey

Testing should prove more than schema validity. A technically valid camt.110 can still be routed to the wrong queue or lose the underlying payment linkage.

A good test pack includes clean operational investigations, AML RFIs, sanctions/compliance RFIs, multiple underlying payments, one payment with multiple investigations, duplicate requests, late responses, partial responses, contradictory evidence, no response, respondent extension requests and cases where privacy restrictions limit what can be disclosed.

Message tests should verify UETR and case-reference preservation, structured category mapping, field lengths, character sets, attachment handling where supported, duplicate detection, replay behaviour, routing to the right legal entity and handling of translated content. Migration tests should compare the structured source with the embedded or generated legacy representation and identify any lost information.

Workflow tests should verify segregation of duties, access restrictions, due-date calculations, reminders, reassignment, escalation, closure controls and immutable audit history. Negative tests should attempt to close a case without a disposition reason, send an RFI without a valid recipient, attach documents from another customer, alter the original payment evidence, or disclose fields the user role is not permitted to share.

Financial-crime acceptance tests should ask whether different evidence produces different decisions. A complete and consistent response should support closure when appropriate; an incomplete or contradictory response should not be auto-cleared merely because a response arrived. Testers should also verify that an incoming RFI can generate a local investigative referral when the information reveals risk at the respondent bank.

Resilience tests should cover Case Management or messaging outages, delayed network acknowledgements, duplicate inbound messages, failed translations, unavailable payment-history systems and document-store failures. The fallback must preserve the investigation state and identifiers so the case can resume without creating parallel uncontrolled email processes.

The control standard to remember

The best RFI process is not the one that sends the most questions or closes the largest number of cases. It is the one that turns a defined uncertainty into proportionate information gathering, preserves evidence and legal boundaries, and reaches a decision that another competent reviewer can reconstruct.

For operations, that means fast and accurately correlated investigations. For compliance, it means evidence that answers the risk question without over-collecting data. For relationship managers, it means clear expectations with respondent institutions. For architects and developers, it means structured identifiers and reliable workflow rather than free-text islands. For testers, it means proving that the process behaves safely when information is missing, late or contradictory. For customers, it means fewer unnecessary delays and fewer repeated requests for information the bank already holds.

The practical discipline is simple: ask only what matters, preserve where the answer came from, assess what it means, and never let the message format replace the judgement.

Swift timetable source, checked 2 October 2026: Structured-address migration extension and 21 September release update. The deferred release includes exceptions/investigations messages on 12 June 2027; structured-address enforcement timing remains separately governed: https://www.swift.com/news-events/news/swift-accepts-community-request-extend-structured-address-migration-iso-20022-payment-messages

Operational deep dive: how an RFI becomes a defensible investigation

The base chapter explains why requests for information matter. This deep dive follows the work at operating level: how a bank decides whether to ask, how the request is built, how the receiving institution investigates, how ISO 20022 Case Management changes the message flow, and how both banks avoid turning an evidence-gathering control into a slow exchange of generic narratives.

Two banks can see the same payment very differently

Take a correspondent chain in which Bank A holds the originator, Bank B is Bank A's USD correspondent, Bank C is the beneficiary's bank, and the beneficiary is a customer of Bank C. Bank B can see the payment instruction and activity through Bank A's correspondent account. It does not automatically hold Bank A's customer's onboarding file, contracts, expected activity or source-of-funds evidence. Bank A has that customer context but may not see the way the customer's payments appear when aggregated with other respondent activity at Bank B.

That asymmetry is the reason an RFI can add value. The correspondent should first exhaust information it already possesses. It should review the payment, related transactions, prior investigations, known respondent profile, public information and any other internal evidence that is lawful and relevant. If the residual question depends on facts reasonably held by the respondent, an RFI becomes proportionate.

The receiving respondent then has a different task. It should not simply forward the question to the customer. It should check its KYC record, account history, payment initiation data, relationship-management notes, prior alerts and documents first. Customer outreach is used where the necessary information is not already held and where outreach is appropriate. This is both more efficient and safer: a bank should not repeatedly ask customers for information it already has, and in sensitive investigations customer contact may need financial-crime or legal approval.

The response should show that the respondent actually evaluated its information. A bare statement that the transaction is “consistent with profile” provides little comfort if it does not explain the profile and the relevant comparison. The correspondent needs enough context to understand why the respondent's conclusion is reasonable, subject to legal limits on disclosure.

Build the RFI from the hypothesis gap

Investigators often speak about “the suspicion” too early. A better technique is to identify a hypothesis and then define the fact that would support or weaken it.

Suppose a respondent customer's payments to a newly introduced beneficiary increase sharply. One hypothesis is that the customer has a genuine new supplier. Another is that the beneficiary is a pass-through entity unrelated to the stated business. The correspondent cannot distinguish those explanations from the payment message alone. The RFI should therefore ask facts that discriminate between them: what is the business relationship, what goods or services are involved, when did the relationship begin, how were the payments funded, do the values align with commercial documents, and is the activity consistent with what the respondent knows about its customer?

This is much stronger than “Please explain these transactions.” It is also stronger than a twenty-question template in which most questions have no bearing on the case. The purpose of an RFI is not to recreate the respondent's entire KYC file. It is to fill a material evidence gap.

A bank can operationalise this by requiring a short risk question field before the RFI can be sent. The field should be visible to QA and second line. If the question cannot be stated clearly, the analyst may not yet understand why external information is needed.

RFI categories should reflect business purpose

One generic RFI category usually becomes a dumping ground. A useful taxonomy separates at least the following business purposes even if the same case platform supports them.

A transaction-monitoring RFI seeks context for unusual or potentially suspicious activity. A payment-transparency enquiry asks for information missing or incomplete in the payment chain. A sanctions or compliance RFI seeks facts necessary to assess a sanctions or other compliance concern. An operational E&I request resolves non-receipt, unable-to-apply, unable-to-execute or similar payment exceptions. A customer information request may be internal to the bank and should not be confused with a bank-to-bank RFI. A formal authority request belongs to legal or regulatory-response processes.

The distinction drives routing and permissions. Payment operations may be allowed to see an unable-to-apply case but not a confidential AML investigation. A sanctions specialist may need immediate escalation and legal interpretation. A correspondent relationship manager may monitor respondent service performance but should not see SAR-restricted details. The platform therefore needs a common case architecture with category-specific access and decision rules.

Swift Case Management and the investigation message pair

For Swift E&I, the current structured pair is camt.110 for an Investigation Request and camt.111 for an Investigation Response. Swift's Case Orchestrator centrally routes these E&I messages rather than treating them as unrestricted bilateral FINplus messages. The service uses the UETR and underlying payment information to support correlation, pre-population, routing and tracking.

That design matters because investigations historically lose time at three points: finding the payment, finding the right bank or team, and understanding what is being asked. A structured case can reduce all three. The underlying transaction reference identifies the payment. Investigation type helps routing. Structured question and response fields reduce dependence on free-text conventions.

Swift also separates payment cancellation from other E&I. Payment cancellation uses camt.056 as the cancellation request and camt.029 as the response. A cancellation is an instruction-related process with its own state and consequences. An RFI is an evidence-gathering process. A bank may have both on the same underlying payment, but they should remain distinct cases linked to the same UETR.

Swift's migration plan is time-sensitive. Earlier material planned receipt of camt.110 with in-flow translation and an embedded MT 199 in November 2026. Swift's 21 September 2026 update instead schedules the deferred SR2026 release, including exceptions and investigations messages, for 12 June 2027. Confirm detailed rollout scope and mandatory milestones in the current Swift customer guidance before production sign-off. This enables a Case Management participant to send the structured request even if the recipient continues processing through a legacy FIN workflow. The previously published November 2027 roadmap envisaged E&I requests and responses to use camt.110 and camt.111 through Case Management, with the formatted legacy E&I messages removed and free-format MT n99 no longer used for E&I. That roadmap also envisaged mandatory Stop and Recall in ISO 20022 form in November 2027. These later milestones require reconciliation against the latest service roadmap; the public release deferral alone does not establish every service-specific obligation.

Earlier Swift publications contained different dates. Delivery teams should therefore use current Swift material and controlled requirements rather than old slides. A bank's internal milestone register should identify the source, source date, requirement date, affected service and owner so a changed network timetable does not leave obsolete rules in production configuration.

The transitional camt.110 plus embedded MT 199 model

The deferred transition deserves detailed testing. A bank not yet processing Case Orchestrator natively may receive a structured camt.110 whose in-flow translation includes an embedded MT 199. The bank can continue the investigation through the legacy FIN path, but the structured source still exists.

The risk is that operations process only the embedded narrative and discard the structured context. If the camt.110 contains identifiers, category data or other information not faithfully represented in the MT 199, a legacy-only back office can make a decision on an incomplete view. Swift's general translation guidance warns that rich MX information can be lost or truncated where legacy formats have no equivalent or insufficient field length.

A robust inbound design therefore stores the original camt.110, the translated representation, translation metadata and the local case together. The UI should show which representation the analyst is reading. Decision-critical structured fields should not disappear simply because a legacy workflow is used for the response.

Outbound handling needs the same discipline. If the bank responds through MT 199 during the transition, the response should retain the Case Management and underlying payment references that allow the initiating institution to correlate it. When the bank later becomes native on camt.111, the case history should continue rather than restart under a new reference.

Correlation keys and why one identifier is never enough

UETR is powerful for cross-border payment tracking, but an investigation data model should not rely on UETR alone. Some cases concern several payments. Some local rails do not use UETR. A payment may have an end-to-end ID, transaction ID, instruction ID, clearing reference, account-servicing reference and internal payment ID. The RFI also has an external investigation ID and a local case ID.

A useful model therefore stores identifiers as typed values with source and scope. The case can say, for example, UETR = X for the underlying Swift payment, InternalPaymentId = Y in the payment hub, MonitoringAlertId = Z in transaction monitoring and ExternalInvestigationId = Q in Case Management. A multi-payment RFI contains an array of underlying transactions rather than concatenating references into narrative text.

Correlation should be idempotent. Receiving the same external message twice must not create duplicate cases. A response arriving before a local routing job completes must still attach to the correct case. A follow-up response should create a new event within the existing case rather than overwrite the earlier response.

Response construction at the respondent bank

The respondent needs its own operating workflow. An inbound request should be validated, classified, assigned to a legal entity and routed to a competent team. The team should know whether the request came from a correspondent customer relationship, from another authorised sharing arrangement or from an unsupported source. A bank should not disclose customer information merely because a message arrived over a technically trusted network.

The analyst then reviews internal evidence. Useful sources can include customer and beneficial-owner profiles, account-opening purpose, expected activity, transaction history, payment initiation details, invoices already held, trade-finance records, prior alerts, relationship-manager records and public sources. The bank should avoid over-collecting. If the question can be answered from existing evidence, there may be no need to contact the customer.

If customer outreach is required, the outreach question should be translated from the correspondent's risk question into language suitable for the customer without revealing protected investigative information. Asking “Why did you pay Company X for USD 450,000 on 2 September?” may be appropriate. Saying “Our correspondent suspects you of laundering money” is not.

Before release, the response should be quality checked against the incoming questions. Every material question should be answered or marked with a reason why the bank cannot answer. The response should distinguish “not available”, “not known”, “not permitted to disclose” and “not applicable”. Those are different states and lead the correspondent to different conclusions.

Privacy and bank secrecy are design inputs

Cross-border RFI processes frequently encounter privacy or bank-secrecy restrictions. The correct control is not a universal “share everything” policy or a universal “privacy prevents sharing” response. The bank needs a jurisdiction matrix maintained by legal and privacy specialists.

That matrix can identify categories such as customer identity data, beneficial ownership, account history, source-of-funds information, copies of documents, internal risk ratings, alert details and SAR/STR information. For each legal entity and recipient context, it should state whether the information may be shared, under what basis, with which approvals, using which channel and subject to which retention or onward-transfer controls.

Where information cannot be disclosed, the respondent may sometimes provide a meaningful alternative—for example, confirming that it has reviewed current KYC and found the transaction consistent with a stated business purpose—if local law and policy permit. Such confirmations are not equivalent to the underlying evidence, and the correspondent should assess their weight accordingly.

SAR and STR confidentiality boundary

A common RFI danger is accidental tipping off. The investigator wants to explain why information is urgent and includes wording such as “we are considering filing a suspicious activity report”. In many jurisdictions that disclosure would be prohibited or tightly restricted.

The safe operational principle is that RFI questions should be framed around factual information needed to understand the activity, not around whether a SAR or STR exists. If the respondent itself has filed a report, it must follow its local law on whether any aspect of that status can be disclosed. The correspondent should not ask for a copy of a SAR or STR as a routine RFI question.

Case access should also reflect this boundary. A general correspondent service team may see that an RFI is overdue without seeing protected suspicious-activity notes. Management dashboards can report response quality without exposing SAR decisions to unauthorised staff.

Sanctions RFI: fact finding under a different clock

A sanctions RFI can look similar to an AML RFI but operate under a different legal clock. Suppose a payment screening alert produces a possible match and the payment contains insufficient information to determine whether the beneficiary is the listed person. The bank may seek date of birth, registration number, address, ownership or other identifying information.

The bank must first apply the sanctions law relevant to its entity and transaction. Some regimes require assets to be frozen when the legal test is met. Others can require rejection or prohibit making funds available. Licences or exemptions can apply. An RFI may help determine identity or ownership, but the bank cannot invent a generic “hold until RFI answered” rule and assume it satisfies every regime.

The workflow should therefore carry a legal-action state separate from the information-request state. A payment may be on compliance hold because policy permits time to resolve a match. Another may already be legally frozen. Another may have been rejected while the institution continues a post-event information request. These states must not be conflated in reporting or customer communication.

Payment-transparency RFI: missing information in the chain

Where required payer or payee information is missing, the issue may be governed by specific local payment-transparency law. The EU's Regulation (EU) 2023/1113 and the EBA Travel Rule Guidelines are a useful example. They set responsibilities for detecting missing or incomplete information and procedures for managing transfers that lack required information. Those procedures can include requesting information and considering repeated failures by another provider.

That is more than a one-off repair. If a counterparty repeatedly sends transfers without required information, the receiving institution should be able to identify the pattern and apply the applicable escalation framework. A data-quality dashboard that measures each payment independently can miss a counterparty-control weakness.

The bank's RFI platform should therefore expose both transaction-level and institution-level history: how often a provider sends deficient data, how often information is supplied after request, how quickly defects recur and whether relationship or regulatory escalation is required under applicable rules.

Monitoring RFI: retrospective context without rewriting history

Transaction-monitoring RFIs are usually retrospective. The payment may already have settled. The investigator seeks context to understand a pattern. This has two important design consequences.

First, the bank should not alter the historical payment message when new information arrives. If the respondent later says the payment was for “machine tools”, that explanation belongs in the investigation evidence. The original remittance field remains whatever it was at execution. The distinction is essential for audit and model testing.

Second, a credible explanation for one transaction may not explain the pattern that caused the alert. An invoice can support a payment amount while repeated payments across multiple counterparties still require explanation. The investigator should assess the RFI against the alert hypothesis rather than treating receipt of documentation as automatic closure.

Quality assurance should sample the question and the answer

RFI QA often reviews whether mandatory fields were completed. That is too shallow. The sample should ask whether the original risk question was clear, whether an external request was necessary, whether the questions were proportionate, whether the respondent's answer was evaluated critically, and whether the final case outcome followed from the evidence.

For outgoing RFIs, QA can identify over-broad questions, repeated requests for information already held, poor explanation of the transaction scope and unreasonable deadlines. For incoming RFIs, QA can identify unsupported assurances, disclosure beyond policy, failure to investigate locally and responses that leave material questions unanswered.

A useful QA finding names the root cause. “RFI inadequate” is not enough. The cause may be a template, missing payment identifiers, poor training, workload pressure, deficient KYC, privacy guidance, routing configuration or a case UI that hides the question from the reviewer. Corrective action should target the cause.

A worked operational example: unable to execute versus AML RFI

A corporate customer sends a cross-border payment to a new beneficiary. The receiving chain cannot execute because a required beneficiary detail is missing. That is an operational information need. The investigation should identify the missing element, obtain it through the permitted workflow, validate it, run any required controls and continue or reject according to the payment rules.

Separately, the sender's correspondent later detects a pattern: the corporate has made twelve payments to four new beneficiaries in the same sector and geography, with values just below its historical high-value threshold. The correspondent asks the respondent to explain the customer's business rationale and relationships. That is a transaction-monitoring RFI.

Both enquiries may concern the same payment. They should not be merged simply because the word RFI appears in both. The operational case may close when the missing beneficiary detail is supplied. The AML case may remain open because the broader pattern still needs explanation. Linking the cases helps investigators see the complete history while preserving the different purpose, SLA, access and outcome.

The operational close standard

An RFI case is ready to close when the bank can show the original question, the information sources reviewed, the request actually sent, the response and its provenance, the analyst's assessment, any follow-up, the decision, the action taken and the person with authority to approve that outcome.

The closure note should not simply repeat the response. It should explain why the response resolved or failed to resolve the concern. If the case was escalated, the investigation record should identify where responsibility moved next. If the respondent could not disclose information, the record should show how that limitation affected residual risk.

This is the difference between correspondence and control. Correspondence proves that messages were exchanged. A control proves that a material uncertainty was identified, investigated and resolved or escalated using evidence and accountable judgement.

Swift timetable source, checked 2 October 2026: Structured-address migration extension and 21 September release update. The deferred release includes exceptions/investigations messages on 12 June 2027; structured-address enforcement timing remains separately governed: https://www.swift.com/news-events/news/swift-accepts-community-request-extend-structured-address-migration-iso-20022-payment-messages

Advanced practice: architecture, controls and proof that the RFI process works

A mature RFI capability is not measured by the number of messages exchanged. It is measured by whether the bank can ask focused questions, preserve the relationship to the underlying payment, receive usable evidence, apply legal sharing rules, reach a consistent decision and learn from repeated information gaps. This section turns that standard into delivery and assurance practices for architects, business analysts, product owners, compliance teams and testers.

Design the case model before the screen

The most common architecture mistake is to begin with a queue screen and then add fields as users request them. That creates a local workflow rather than an investigation model. The better sequence starts with the entities and events that must survive end to end.

The core entities are the investigation case, underlying payment or payment set, parties in scope, request, question, requested evidence, response, evidence item, assessment, decision and action. Each needs identifiers, timestamps, ownership and status. The model should allow one case to cover several payments and one payment to have several cases, because real investigations are many-to-many.

A response is not a text field on the request. It is its own event. There can be a partial response, an extension request, a follow-up response and a corrected response. If the system overwrites the previous text, the audit trail disappears. The same principle applies to questions: follow-up questions should be new events linked to the original request, not edits that make it appear that the recipient was asked something different from what was actually sent.

Evidence should be versioned or immutable. An invoice received on 10 September remains the invoice received on 10 September even if a revised invoice arrives on 12 September. The case can record which version the analyst relied on. This becomes important when a later investigation finds that the revised document was misleading.

A practical canonical RFI object

An enterprise platform benefits from a canonical object independent of the transport channel. A useful object contains the following logical groups.

Case identity includes the internal case ID, external investigation ID, case type, legal entity, owning team, status, priority and confidentiality class.

Payment linkage contains UETR where applicable, instruction ID, end-to-end ID, transaction ID, clearing reference, internal payment ID, amount, currency, value date and source system. For pattern cases, it contains a controlled collection of payments rather than narrative references.

Institution linkage records the requesting institution, respondent, BIC or other institution identifier, correspondent relationship, account relationship and any downstream institution in scope.

Risk question stores the investigative reason in business language, category and relevant alert or review reference. The field should not expose protected SAR information to users who are not authorised to see it.

Request data stores the questions, evidence requested, date sent, channel, due date, communication contact, language and any applicable legal-sharing basis or restriction classification.

Response data records receipt timestamp, responder, answers, evidence references, disclosure limitations, completeness state and whether the respondent requested more time.

Assessment data records which facts support or contradict the working explanation, what remains unknown, whether the response was considered adequate, and the analyst's recommendation.

Decision and action record closure, escalation, restriction, monitoring change, KYC refresh, sanctions referral, fraud referral, SAR/STR consideration or other action, including approver and decision date.

The external camt.110 or camt.111 is then a representation of part of this business object, not the bank's entire data model. That separation allows the same case service to support domestic rails, correspondent RFIs, APIs or GUI workflows without forcing every process into Swift-specific fields.

State design should expose waiting rather than hide it

A useful state model distinguishes work performed by the bank from time waiting on another party. Example states include Draft, PendingApproval, Sent, AwaitingAcknowledgement, AwaitingExternalResponse, ResponseReceived, UnderAssessment, FollowUpRequired, Escalated, DecisionPending, Closed and Cancelled.

The exact names can vary, but the purpose is important. If every open case is simply In Progress, management cannot tell whether staff capacity or external response time causes the backlog. Operations cannot prioritise cases approaching external deadlines. Compliance cannot see whether analysts are leaving responses unassessed for days after they arrive.

State transitions should have guards. A case should not move to Sent without a valid recipient and at least one question. It should not move to Closed without a disposition and required approval. A ResponseReceived event should reset or recalculate the internal assessment deadline rather than leave the original external response clock running.

The platform should record both event time and processing time. A response received at 17:58 but loaded into the analyst queue at 08:30 next morning has two meaningful timestamps. During incidents, those differences explain whether delay occurred at the network, ingestion layer or operations team.

Routing rules need financial-crime context

Routing an investigation only by currency or BIC is insufficient. The platform may need to consider legal entity, payment rail, case category, customer segment, language, sanctions/compliance sensitivity, respondent relationship and operating hours.

A sanctions RFI should route to a sanctions-capable team even if the payment came through the normal E&I queue. A correspondent transaction-monitoring RFI may need a specialised respondent-RFI team familiar with KYC disclosure rules. An unable-to-apply operational request should not enter the AML investigations queue simply because it uses the same camt.110 family.

Routing must also handle absence. If the named owner is unavailable, the case needs a team queue or delegated owner. Time-sensitive investigation processes should not depend on personal mailboxes. Escalation rules should use the risk and case type, not only elapsed time.

Data minimisation can be implemented technically

Privacy principles are easier to follow when the system helps users. A request builder can show only evidence categories permitted for the case type and recipient relationship. Sensitive attachments can require additional approval. Fields classified as SAR-restricted can be excluded automatically from outbound messages. Data-retention rules can differ by case class and jurisdiction.

The platform can also warn when a user asks for information already present in the bank's own systems. For example, if the payment message already contains the beneficiary address and the RFI template asks for the same address, the tool can prompt the analyst to confirm why external verification is needed. This reduces unnecessary RFIs and customer burden.

Free-text fields deserve particular attention. Users can defeat carefully designed data controls by pasting large amounts of KYC or suspicious-activity narrative into a general comments field. Data-loss-prevention rules, field guidance and QA sampling should therefore cover free text as well as structured attachments.

Distinguish response adequacy from response sentiment

Automation can help classify a response but should not equate positive wording with adequacy. “No concerns identified” is a sentiment. Adequacy depends on whether the respondent answered the material question with enough evidence.

A response-quality model can use deterministic checks such as: all material questions addressed; required transaction references matched; requested period covered; evidence type supplied where necessary; contradictory values flagged; disclosure limitation stated where relevant; and response received from an authorised channel. Those checks create a completeness signal.

A second layer can identify semantic contradictions, for example where the response says “long-standing supplier” but the respondent's own supplied date says the relationship began two weeks earlier. Such automation should surface review points rather than make a financial-crime conclusion automatically.

Natural-language tools can help summarise long responses, but the original response and evidence remain authoritative. A model-generated summary should be labelled as derived content, carry model/version metadata where used in a controlled bank setting, and never replace source evidence in the case record.

Message mapping requirements for camt.110 and camt.111

A mapping specification should begin with the current Swift usage guidelines and Case Management rulebook available to the institution. Public Swift material confirms the high-level message roles, but production implementation depends on the actual usage guideline version.

For every mapped field, the BA should record the source system, source data element, canonical field, target message element, transformation rule, mandatory condition, validation, permitted values, truncation handling, error outcome and ownership. The specification should distinguish network-required elements from bank-required fields and from optional enrichment.

Identifiers should never be transformed casually. A UETR should remain a UETR, not be copied into an untyped local reference. If the receiving system cannot store a full external case ID, the solution should fix the data model rather than truncate the identifier.

Narrative mapping deserves special testing. Structured question categories can coexist with explanatory free text. The mapping should not duplicate the same sentence into several fields or merge several questions into one ambiguous paragraph. When a field is omitted because the legacy translation has no equivalent, the omission should be detectable.

Translation reconciliation is a control

During the 2026 transition, a bank may process both the original structured camt.110 and an embedded MT 199 representation. That creates a new control: translation reconciliation.

The bank should define which structured fields are expected to survive the translation, which are not represented, and which may be truncated. Test cases should include maximum-length values, non-Latin characters where permitted, multiple party references, long investigation narratives and all supported RFI subtypes. The test result should identify information loss explicitly.

Where important structured information cannot be represented in the embedded MT, the legacy operations UI should retrieve the original structured message or a canonical rendering. It is not enough to state that the network translation succeeded. Technical success can coexist with semantic loss.

The reverse transition also matters. If an analyst responds in a legacy interface and the external process expects structured status, the integration layer should not invent a precise code unsupported by the analyst's actual decision. Mappings from narrative to structured outcome need deterministic business rules or human selection.

Duplicate and replay control

Investigation messages are business events and can be retried. Network or integration failures can cause the same message to be delivered more than once. Without idempotency, duplicate RFIs can create duplicate customer outreach, duplicate cases or inconsistent responses.

The inbound service should use stable external message and case identifiers to detect duplicates. A byte-for-byte duplicate can normally be acknowledged without creating a new event. A message with the same case ID but changed content may be an amendment or follow-up and should be processed according to the rulebook rather than silently deduplicated.

Outbound retry logic should avoid generating a new business request each time transport fails. The system needs to distinguish “message not delivered” from “new RFI required”. Operational dashboards should surface stuck transport events separately from respondent non-response.

Access-control design

RFI cases frequently combine payment data, KYC, personal information, internal risk reasoning and potentially sanctions or suspicious-activity considerations. Role-based access therefore needs more nuance than “financial crime user”.

A payment-operations role may access operational investigation data and the underlying payment but not confidential AML notes. An AML investigator may access customer and monitoring context. A sanctions analyst may access sanctions-match evidence. A relationship manager may see service-level and respondent-quality information without SAR-related case detail. QA and audit roles need read access appropriate to their assurance mandate. Administrators should not automatically receive unrestricted business-data access merely because they manage the platform.

Privileged access, document downloads, exports and manual data changes should be logged. Case assignment should not be used as the only access control because users sometimes need temporary collaboration without becoming the formal owner.

An acceptance-criteria pack for business analysts

Strong requirements can be written as observable outcomes rather than vague statements.

Correlation: When a valid inbound investigation request contains an underlying UETR, the system shall link it to the matching payment where exactly one match exists and retain the external investigation reference. If no match or multiple matches exist, the case shall route to controlled exception handling without guessing.

Immutability: The original inbound and outbound message representations shall be retained unchanged. Analyst comments and later evidence shall be stored as separate case events.

Question quality: An outbound financial-crime RFI shall require a business reason and at least one material question. The system shall prevent a blank or template-only request from being sent.

Response quality: Receipt of a response shall not automatically close the case. A user with the appropriate role must record whether the response is complete, partial, contradictory, legally constrained or non-responsive and provide a disposition rationale.

Confidentiality: Fields classified as protected suspicious-activity information shall not be available for outbound mapping. Attempts to copy protected data into restricted outbound fields shall be blocked or alerted according to policy.

SLA: The system shall calculate external response due dates using the applicable case-type calendar and shall keep legal/regulatory deadlines as separate fields so one cannot overwrite the other.

Auditability: Every status change, assignment, outgoing request, incoming response, attachment event, assessment, override and closure shall be timestamped with actor and source.

Resilience: If the external messaging service is unavailable, cases shall remain queued with their identifiers intact; retry shall not create duplicate business requests.

These criteria are more useful to developers and testers than a requirement saying “system must support RFI processing”.

Test design: golden journeys are not enough

A golden journey proves that one correct request receives one correct response. It does not prove the control.

The functional test suite should include a request with one payment, one with a group of payments, a response containing all answers, a partial response, a response stating a legal disclosure restriction, a contradictory response, no response, a respondent extension request, a follow-up RFI, a duplicate response and an unsolicited message that cannot be correlated.

Data-quality tests should mutate identifiers, dates, amounts, BICs, names and references. They should verify that an incorrect UETR does not silently link to a similar payment, and that a valid UETR with a mismatched amount triggers review rather than overwriting the payment record.

Access-control tests should attempt to view and export a sanctions-sensitive case from a general operations role, copy protected narrative into an outbound message, attach a document from another customer and close a case without required approval.

Migration tests should compare the native camt.110 with the embedded MT 199 and record every information difference. The goal is not to force two formats to be identical; the goal is to know which information is preserved and ensure analysts retain access to what matters.

Performance tests should simulate bursts. A sanctions-list change, major correspondent review or network incident can produce volumes far above normal daily demand. The platform should be tested for queue ingestion, routing, search and attachment access under those conditions.

Resilience tests should fail the message gateway after the case is approved but before network acknowledgement, fail the case database after message receipt, delay payment-hub lookup, deliver messages out of order and replay acknowledgements. Recovery should preserve business state without duplicate outreach.

Quality assurance themes for completed cases

A manual QA sample can score five dimensions.

Necessity asks whether the RFI was needed after internal research. Focus asks whether the questions matched the risk gap. Evidence asks whether response assertions were supported and sourced. Judgement asks whether the analyst assessed the response rather than simply copying it. Outcome asks whether the action followed policy and the facts.

The sample should include closed-as-explained cases and escalated cases. Reviewing only cases that became SARs or sanctions escalations creates confirmation bias. Reviewing only closures can miss overly permissive decisioning.

QA results should be linked to root causes and owners. If many analysts ask the same unnecessary question, the template owner may need to change the form. If responses are consistently hard to assess because customer data is stale, the KYC process may need remediation. If case correlation fails, technology owns part of the control weakness.

Management metrics with a numerator and a reason

Metrics should support decisions. A useful RFI dashboard can show:

• first-response adequacy rate, with reasons for inadequacy;
• median and 90th-percentile external response times by respondent and case type;
• internal assessment time after response receipt;
• proportion of RFIs avoided because internal information resolved the question;
• follow-up rate and the questions causing follow-up;
• non-response rate and resulting case outcomes;
• respondents with recurring missing payment information;
• cases where an RFI triggered local KYC refresh, monitoring referral or relationship action;
• customer-impact days for live-payment investigations;
• number of cases where translation or correlation defects affected processing.

Volume alone can be misleading. A fall in RFI volume may mean better payment transparency, or it may mean investigators stopped asking necessary questions because the queue is overloaded. Metrics require context and QA evidence.

Governance across first and second line

First line owns the operational execution of the process and should understand why controls exist. Financial-crime operations may sit organizationally in first or second line depending on the institution, but decision ownership must be explicit. Relationship teams own respondent engagement and service expectations without compromising investigative independence.

Second-line policy should define when RFIs are appropriate, information-sharing boundaries, escalation standards, QA expectations and governance for repeated respondent weaknesses. Legal and privacy specialists maintain the jurisdictional interpretation. Technology owns availability, integrity and access controls. Data owners define source quality. Senior governance reviews material themes and residual risk.

A policy committee does not need to approve every question. It does need to approve the framework that tells analysts what they may ask, what they may share, when they must escalate and which decisions require specialist approval.

Change governance for a moving external standard

The E&I environment is changing quickly. Swift's 2026 and 2027 Case Management milestones, evolving usage guidelines, ISO 20022 message versions and local payment-transparency regulation can all affect the solution.

Every external requirement should therefore be stored with a source, publication date, effective date, affected products, legal entities, technical components, owner and implementation status. A new Swift timeline should trigger review of message routing, testing, customer or correspondent communications and operational procedures. An updated legal interpretation should trigger rule and training changes. A new message version should trigger mapping and regression testing.

This is especially important because publicly available articles can preserve superseded milestones. A delivery team should prefer the latest official source and record why an older date is no longer used.

Advanced mini case: the response that looks complete but is not

A correspondent's monitoring system identifies repeated payments from a respondent customer's account to four companies in different countries. The values and timing suggest possible trade-related layering. The correspondent sends a focused RFI asking for the customer's business, relationship to each beneficiary, goods or services, source of funds and supporting commercial evidence.

The respondent replies within five business days. The response is polished. It provides the customer's incorporation certificate, beneficial-owner details, a statement that the customer trades electronics, and four invoices matching the payment values. On a simple completeness dashboard, the response scores highly.

The correspondent investigator checks the invoices rather than merely recording their presence. Two invoices use identical invoice numbers. The goods descriptions are generic. The supposed suppliers' websites describe unrelated services. The originator's account was funded shortly before each payment by incoming transfers from parties unrelated to its stated business. The response therefore increases concern rather than resolving it.

The correspondent sends a narrow follow-up asking about the duplicated invoices, commercial relationship and source of the incoming funds. The respondent's local team then discovers that the customer had recently changed its business model but never updated KYC, and that a relationship manager accepted the invoices during an earlier review without independent verification. The respondent escalates locally and refreshes the customer investigation.

The lesson is operationally important: response quality is not document count. A fast, complete-looking answer can contain contradictions that only a competent assessment reveals. Systems should support that judgement rather than reward attachment volume.

Advanced mini case: the legally constrained respondent

A correspondent asks a respondent for detailed beneficial-owner identity documents and copies of customer communications. The respondent's jurisdiction permits it to confirm certain KYC facts but restricts cross-border disclosure of copies without additional legal basis.

A weak response says only “cannot provide due to GDPR” even though GDPR is not a universal prohibition on such sharing and may not even be the relevant law. A stronger response, reviewed under the respondent's actual legal framework, explains that it cannot provide the requested copies, confirms the current beneficial owners and ownership percentages where permitted, confirms that identity was verified under its KYC process, provides the customer's business profile and answers the transaction-purpose questions.

The correspondent then evaluates whether those confirmations are sufficient for its risk question. If not, it can escalate through the relationship or legal channel rather than repeatedly asking for the same prohibited documents. The case records the limitation as a legal constraint, not as automatic respondent non-cooperation.

What “done” means for a production RFI capability

A bank can call the capability production-ready when it can prove several things together: the right case reaches the right team; the original payment and identifiers remain traceable; questions are focused and lawful; structured and legacy message transitions do not hide decision-critical data; responses preserve provenance; incomplete or contradictory responses cannot auto-close the case; sensitive information is protected; deadlines are visible; outages recover without duplicate requests; management can identify respondent and root-cause trends; and QA can reconstruct why the bank reached its decision.

That is a much higher standard than successfully sending a camt.110. The message is the carrier. The control is the complete evidence and decision lifecycle around it.

References and further reading

The chapter was reviewed against the following public, authoritative sources on 20 September 2026. Network and regulatory implementation dates can change, so production teams should always confirm the current rulebook, usage guideline and local legal position before implementing a control.

• Financial Action Task Force, The FATF Recommendations, updated June 2026: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
• Financial Action Task Force, Public consultation on guidance to increase payment transparency under strengthened Recommendation 16, 24 June 2026: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/R16-Public-Consultation-June-2026.html
• The Wolfsberg Group, Transaction Monitoring Request for Information Best Practice Guidance, August 2022: https://wolfsberg-group.org/resources/legacy/57
• The Wolfsberg Group, Payment Transparency Standards, 2023: https://wolfsberg-group.org/resources/legacy/136
• The Wolfsberg Group, Guidance on Payment Transparency: Roles and Responsibilities, December 2024: https://wolfsberg-group.org/resources/general/200
• Swift, ISO 20022: Exceptions and Investigations, current migration and message overview: https://www.swift.com/pt/node/310548
• Swift, Transforming exceptions and investigations, current Case Management and migration explanation: https://www.swift.com/news-events/news/transforming-exceptions-and-investigations
• Swift, ISO 20022 in bytes for payments: The journey continues. Earlier migration background; the November 2026 timetable is superseded by the later release announcement: https://www.swift.com/ja/node/310528
• Swift, ISO 20022 to MT Translation, including camt.110 in-flow translation and MX-to-MT information-loss considerations: https://www.swift.com/de/node/308151
• ISO 20022, Message definitions and repository: https://www.iso20022.org/iso-20022-message-definitions
• European Union, Regulation (EU) 2023/1113 on information accompanying transfers of funds and certain crypto-assets: https://eur-lex.europa.eu/eli/reg/2023/1113/oj
• European Banking Authority, Travel Rule Guidelines under Regulation (EU) 2023/1113, applicable from 30 December 2024: https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/anti-money-laundering-and-countering-financing-terrorism/guidelines-information-requirements-relation-transfers-funds-and-certain-crypto-assets-transfers
• FFIEC BSA/AML Examination Manual, Due Diligence Programs for Correspondent Accounts for Foreign Financial Institutions: https://bsaaml.ffiec.gov/manual/AssessingComplianceWithBSARegulatoryRequirements/10
• FinCEN, Information Sharing Under Section 314(b), including the June 2026 fact sheet: https://www.fincen.gov/resources/section-314b

Swift timetable source, checked 2 October 2026: Structured-address migration extension and 21 September release update. The deferred release includes exceptions/investigations messages on 12 June 2027; structured-address enforcement timing remains separately governed: https://www.swift.com/news-events/news/swift-accepts-community-request-extend-structured-address-migration-iso-20022-payment-messages