Customer, Account and Counterparty Review

A financial-crime investigation becomes unreliable when it looks only at the transaction that triggered the alert. The payment may be unusual, but the bank's real question is wider: who is the customer, how is the relationship actually being used, and who sits on the other side of the activity? Customer, account and counterparty review is the discipline that answers those questions before an investigator decides whether concern is resolved, requires further due diligence, should be escalated for suspicious activity reporting, or needs another risk response.

The simplest mental model has three lenses. The customer lens asks who the bank believes it is serving, why the relationship exists, who owns or controls it, and what activity was reasonably expected. The account lens asks how value actually moves across the customer's products, accounts, channels and time periods. The counterparty lens asks who repeatedly sends or receives value, what relationship those parties appear to have with the customer, and whether the network makes economic sense. None of the lenses is sufficient alone. The control becomes useful when the three are reconciled.

A salaried customer receiving one unusual transfer is different from a salaried customer receiving hundreds of unrelated third-party credits across two accounts and sending most of them within hours to a small set of beneficiaries. A trading company paying an overseas supplier can be ordinary. The same payment may deserve closer review when the supplier is unrelated to the declared business, shares directors with another high-risk counterparty, was incorporated shortly before the activity began, or appears in a recurring pass-through pattern. These facts do not prove criminality. They determine what questions the bank must ask and what evidence is needed to answer them.

FATF Recommendation 10 provides the global foundation. It requires customer due diligence at the start of relevant relationships and ongoing due diligence throughout them, including scrutiny of transactions so that activity remains consistent with the institution's knowledge of the customer, the customer's business and risk profile and, where necessary, the source of funds. FATF also expects institutions to identify beneficial owners and understand ownership and control structures for legal persons and arrangements. Those standards are global architecture, not a universal case procedure. Local laws define the precise duties, thresholds, retention requirements, reporting tests and permitted customer actions.

The practical purpose of this chapter is therefore not to create one worldwide checklist. It is to show how an investigator reconstructs a relationship in a way that is accurate, proportionate, explainable and implementable in a real bank.

1. Review the relationship, not the alert in isolation

An alert usually represents a narrow view of behaviour. A transaction-monitoring rule may have examined seven days of activity in one account. A fraud referral may describe a beneficiary, device or authentication event. A sanctions hand-off may identify an ownership or routing concern. A relationship manager may raise a qualitative concern after speaking with the customer. The investigator's first task is to determine the correct relationship perimeter rather than accept the alert perimeter automatically.

That perimeter can include all accounts held by the customer within the relevant legal entity, linked products, cards, deposits, loans, trade-finance facilities, cash-management arrangements, merchant or acquiring activity, investment relationships and other services where the bank is permitted and able to access them. It can also include related customers where the facts justify expansion: joint account holders, businesses controlled by the same owners, authorised signatories, guarantors, connected legal entities, or customers sharing meaningful operational links. Expansion should be risk-led and lawful, not a general invitation to search every available database.

The distinction matters because financial crime frequently exploits organisational boundaries. One account receives funds while another account disperses them. A personal account funds a company account. A card or wallet relationship creates value that later exits through a bank transfer. A group of companies uses different products but the same controller. A review that stays inside the triggering product may produce a technically neat but factually incomplete conclusion.

The investigator should record why the scope was chosen. If the case covers six months of activity across three accounts and two related companies, the reason should be visible. If a linked relationship is excluded because the bank lacks a lawful basis, access right or evidential connection, that limitation should also be visible. A future reviewer should be able to distinguish a deliberate boundary from an accidental blind spot.

2. Start with what the bank knew, and when it knew it

Customer files change over time. Occupation, business activity, directors, beneficial owners, expected turnover, countries of operation, products, risk rating and source-of-funds information can all be updated. A common investigation error is to use today's customer profile to explain activity that occurred under a materially different profile months or years earlier.

A defensible review therefore needs point-in-time customer context. The investigator should be able to reconstruct, as far as the bank's records permit, what information was held when the relevant activity occurred. This is especially important where a customer changed business model, ownership or geography; where KYC was refreshed after the alert period; or where a remediation project corrected earlier data.

For an individual, relevant context may include identity, residence, occupation, employer, expected income, declared purpose of the account, products held and expected transaction patterns. For a legal entity, it may include legal form, registered and operating addresses, nature of business, ownership and control structure, directors, authorised persons, expected customers and suppliers, jurisdictions, turnover, products and source of funding. The review should use only what matters to the risk question rather than reproducing the entire KYC record.

Historical accuracy also changes how contradictions are interpreted. Suppose a customer was onboarded as a domestic consulting business, later updated its profile to include international commodity trading, and the alert concerns commodity-related transfers made before that update. The current profile does not automatically validate the earlier activity. The investigator needs to establish when the business changed, whether the bank was informed, whether the new activity was plausible at the time, and whether the delayed update itself is relevant to risk.

System design must support this. If customer data is overwritten rather than versioned, the investigation platform may show only the latest value. Business analysts should therefore treat effective dates, historical versions and evidence provenance as core requirements, not optional audit enhancements.

3. Customer risk rating is context, not the conclusion

A customer risk rating can guide the intensity of due diligence and monitoring, but it should not substitute for investigation. A low-risk customer can engage in suspicious activity. A high-risk customer can conduct perfectly legitimate business. The investigator should understand the factors behind the rating instead of treating the final score as self-explanatory.

Useful questions include whether the rating reflects customer type, geography, product, delivery channel, ownership complexity, PEP exposure, sector, correspondent activity or another factor; whether the rating was current during the review period; whether new facts should trigger reassessment; and whether data defects affected the score. A rating that was calculated with a missing country field or outdated beneficial owner may be less informative than its numeric value suggests.

The same principle applies to enhanced due diligence. An EDD file may contain valuable information about source of wealth, source of funds, business rationale, counterparties or ownership. But the existence of EDD does not prove that later activity is legitimate. The investigator should test whether the observed behaviour is consistent with the evidence and assumptions on which the relationship was accepted.

A mature case record therefore separates customer risk classification from investigation judgement. The first describes the baseline risk of serving the customer. The second evaluates specific behaviour and evidence. Keeping those concepts separate reduces both complacency and bias.

4. Understand ownership, control and authority

For companies, partnerships, trusts and other arrangements, the name on the account may not identify the people who ultimately own, control or benefit from the relationship. FATF's strengthened beneficial-ownership standards emphasise adequate, accurate and up-to-date information on the true owners of legal persons, while Recommendation 25 addresses legal arrangements such as trusts. Banks apply those principles through local CDD requirements and their own risk-based procedures.

During an investigation, ownership and control matter for several reasons. A counterparty may appear independent but share the same beneficial owner as the customer. A director or authorised signatory may operate several accounts. A newly introduced controller may coincide with a sharp change in activity. A trust beneficiary, settlor, protector or other party may be relevant depending on the arrangement and applicable law. Nominee structures may require additional evidence to understand who is actually directing activity.

The investigator should distinguish different relationship types rather than collapse them into a generic related party label. Legal ownership, beneficial ownership, directorship, signing authority, family relationship, shared address, shared device, commercial relationship and inferred network association are not equivalent. Each has different evidential weight.

Entity-resolution technology can help identify links, but human review must understand what created them. Two companies sharing a registered agent address may be unrelated. Two retail customers using the same IP address may be family members, employees on one corporate network, or participants in a mule network. A graph should expose relationships for investigation, not convert correlation into guilt.

5. Reconstruct the customer's full account behaviour

The account review should answer a simple question: how is the relationship actually being used? That requires more than checking whether individual transactions exceed thresholds.

The investigator should normally examine the pattern of inflows, outflows and balances over an appropriate period. Useful features can include transaction count and value, cash activity, domestic and cross-border payments, currencies, card or merchant activity, internal transfers, salary or business receipts, loans, investment flows, virtual-asset counterparties where visible, ATM activity, beneficiary creation, payment channels, transaction timing, refunds, reversals and returned payments. Which features matter depends on the customer and the risk question.

Behaviour should be compared with both the customer's own history and the bank's documented understanding of expected use. Sudden change can matter more than absolute value. A small account that changes from monthly salary and household spending to daily third-party credits followed by immediate outbound transfers may deserve more attention than a high-turnover corporate account behaving exactly as expected.

The review should also consider the shape of money movement. Rapid pass-through activity, fan-in from many senders, fan-out to many beneficiaries, repeated round amounts, circular flows, rapid cash withdrawal, movement through newly opened accounts, dormant-account reactivation, repeated returns, unexplained currency conversions or unusual sequencing can all be relevant. They remain indicators rather than proof. The investigator must test them against customer context and plausible economic purpose.

A useful technique is to separate activity into functional categories: ordinary operating activity, customer or salary receipts, internal transfers, financing, cash, high-risk corridors, newly seen counterparties, rapid pass-through flows and unexplained residual activity. This makes the narrative easier to understand than a long list of individual transactions.

6. Do not let multiple accounts hide one economic story

Banks often organise data by product or account because those structures reflect systems and legal contracts. Criminal behaviour is not obliged to respect the same boundaries. A customer may receive funds into one account, transfer internally to another, convert currency, and then pay a counterparty from a third product. If each leg is reviewed separately, the pattern can disappear.

For investigations, internal transfers should therefore be identified and linked so the analyst can avoid double-counting value while still following the flow. An investigator should know whether apparent incoming value is genuinely external or simply money returning from another account controlled by the same customer. The same applies to corporate groups where treasury structures legitimately move funds between entities.

Account aggregation also requires care. Combining all products can reveal the relationship but may hide product-specific risk. A cash-intensive current account, trade-finance facility and securities account should not be reduced to one total turnover number. Good analysis preserves both the consolidated view and the product context.

This has direct architecture implications. A customer master identifier, legal-entity identifier or well-governed cross-system linkage is essential. Where the bank cannot reliably connect accounts to the same customer, the limitation is itself a financial-crime data-quality issue. Where accounts are linked using probabilistic entity matching, the confidence and rationale for that link should be visible to the investigator.

7. Counterparty review asks who is on the other side of the money

The counterparty lens is often where an investigation moves from isolated transactions to an economic story. A counterparty is the person or entity sending value to, receiving value from, or otherwise participating in the customer's activity. The bank's visibility varies by rail. A domestic account transfer may provide structured account and bank identifiers. A cross-border payment may include debtor, creditor, agents, ultimate parties, addresses and remittance data. Cash provides very limited counterparty information. Card transactions may show merchant and acquirer information rather than the merchant's beneficial owner. Trade finance can provide documentary parties that never appear as payment-account holders.

Investigators should not assume that the displayed counterparty name is a verified identity. The name may have been entered by the customer, populated by another bank, truncated, transliterated or transformed. Account identifiers, institution identifiers, merchant IDs, wallet addresses and other attributes can help establish whether apparently different names refer to the same counterparty.

Counterparty analysis usually begins with frequency, value, first seen, last seen and direction. It then asks which parties are new, dominant, repeated, shared across linked customers or inconsistent with the stated business. For a corporate customer, the key parties may be suppliers, buyers, agents, freight forwarders, brokers, related companies or service providers. For a retail customer, they may be employers, family, merchants, lenders, investment platforms or individuals.

The point is not to label every counterparty. It is to identify which relationships materially affect the investigation.

8. Build a counterparty network only when it adds meaning

Network analysis is powerful when the case involves repeated relationships, coordination or layered movement. It is unnecessary when a simple transaction explanation resolves the concern.

When a network view is justified, the investigator should distinguish nodes and edges clearly. A node may represent a customer, account, legal entity, individual, merchant, wallet or other relevant party. An edge should represent an observed relationship such as payment, ownership, directorship, shared contact information or authorised access. The evidence source and date should be retained.

Several network patterns can be useful. Many customers paying one beneficiary can indicate an aggregator, merchant, family support arrangement or criminal collection point. One customer paying many newly created beneficiaries may reflect payroll, marketplace activity or layering. Circular payments can indicate legitimate treasury movement or artificial transaction chains. Shared counterparties across customers can expose a common employer, supplier, scam beneficiary or mule controller. The investigator must test context before assigning meaning.

A strong network view also shows negative evidence. If a suspected related company has no shared owner, address, director, device or transaction after verification, that absence may weaken the hypothesis. Investigations become more defensible when they record what was tested and disproved, not only what supported concern.

9. Compare expected activity with observed activity carefully

Expected activity is useful only when it is specific enough to test. A profile that says international payments expected provides little value. A stronger profile might say the company imports electronic components from named or known supplier types in particular regions, expects monthly turnover within a broad range, pays freight providers and tax authorities, and receives funds from domestic wholesale customers. The investigator can then compare actual behaviour with a meaningful baseline.

Expected activity should not become a rigid limit. Businesses grow, individuals change jobs, families receive inheritances, companies enter new markets and customers adopt new products. The question is whether the change is understood and credible, not whether the customer stayed permanently inside an onboarding estimate.

When activity differs materially from the profile, the investigator should ask whether the KYC is stale, whether the relationship legitimately changed, whether the customer failed to disclose a material change, or whether the activity indicates misuse. This may trigger an event-driven KYC review even if the financial-crime case itself is closed without reporting.

The relationship between monitoring and CDD should therefore operate as a feedback loop. The UK's FCA describes ongoing monitoring as scrutinising transactions for consistency with what the firm knows about the customer and keeping CDD information current. The FFIEC manual similarly describes U.S. ongoing monitoring as including risk-based procedures to identify and report suspicious transactions and to maintain and update customer information, with updating driven by events identified through normal monitoring. Those are jurisdiction-specific expressions of a broader principle: monitoring should challenge the customer profile, and the profile should improve monitoring.

10. Use counterparty and geography risk as context, not automatic suspicion

Countries, sectors and counterparties can change the risk of a transaction, but geographic or category labels should not decide the case by themselves. A transfer to a country identified as higher risk may be legitimate trade, salary, family support or investment. A customer in a cash-intensive sector may have a normal reason for cash activity. A relationship with a money-service business may be entirely lawful.

The investigator should understand what creates the risk. Is the issue weak transparency, sanctions exposure, corruption risk, conflict, secrecy, known typologies, regulatory status, product vulnerability or something else? Does the counterparty itself have adverse information or merely operate in a higher-risk environment? Is the customer's purpose coherent with that exposure?

This distinction supports proportionality and financial inclusion. The FCA's current de-risking guidance, updated in February 2026, reiterates that effective AML risk management does not require wholesale withdrawal from entire customer categories. Investigation conclusions should therefore be customer- and activity-specific unless applicable law creates a direct prohibition.

11. External research must be attributable and time-aware

Investigators may use company registries, official licensing databases, sanctions lists, regulator notices, court records, public filings, trusted news sources and commercial data providers. The source and date matter because information changes. A company may have changed directors after the transaction period. A licence may have been issued later. A negative news article may relate to a namesake. A corporate website describes what the company claims about itself, not independent proof of what it does.

External information should therefore be classified by source quality and relevance. Official registry information may establish legal existence or recorded directors. It may not prove beneficial ownership if the registry does not capture it reliably. Adverse media can create a reason for further review but should not be presented as an adjudicated fact unless the underlying authority supports that conclusion.

Screenshots alone are weak evidence if they omit the URL, retrieval date, underlying record and search logic. Where the bank's evidence platform permits it, analysts should preserve the source reference, relevant extract, access date and the identity-resolution reasoning that connects the external record to the customer or counterparty.

12. Request additional information to answer a defined gap

A customer request for information should be designed around the investigation hypothesis. Please explain these transactions often produces an unhelpful response. A stronger request asks what commercial relationship exists with specified counterparties, what goods or services were provided, why payments were split or routed through third parties, what supports the source of funds, and whether the pattern is expected to continue.

The analyst should know in advance what evidence would make the explanation more or less credible. An invoice can support a transaction, but an invoice created by the customer is not independent proof. Shipping documents may support a trade, but discrepancies can create further questions. Contracts, payroll records, tax documents, registry data, proof of sale or other material may help depending on the case and lawful scope.

Contact must also respect confidentiality and tipping-off requirements. FATF Recommendation 21 provides a global principle against disclosing the fact that an STR or related information is being filed, while local laws define the exact scope and exceptions. A bank should not use one universal contact script. Procedures need to specify when customer contact is permitted, when an MLRO or legal team must approve it, and how the rationale is documented.

Customer non-response is evidence but not automatically proof of suspicion. The investigator should assess what information was requested, whether the customer had a reasonable opportunity to respond, whether the request was clear, what other evidence exists and what local policy or law requires next.

13. Separate facts, inferences and unresolved questions

A high-quality case note distinguishes three categories.

Facts are supported directly by reliable evidence: a payment was sent on a date, a customer held a particular account, a registry showed a director, or a device identifier was recorded by the bank.

Inferences are reasoned interpretations: the activity appears to be pass-through, two entities may be connected, the stated business purpose seems inconsistent with transaction behaviour, or the pattern resembles a known typology.

Unresolved questions identify what the bank cannot establish: the economic purpose of a set of transfers, the true controller of a counterparty, the reason for a sudden shift in geography, or the source of a particular inflow.

This separation prevents the case narrative from becoming more certain as it is copied between teams. It also improves SAR/STR quality when reporting is required because the report can describe observed behaviour without overstating what the bank knows.

14. Decide whether the review should widen, deepen or close

Not every counterparty deserves a full investigation. The analyst needs a proportionate decision point.

A review may close when the activity is understood, evidence is coherent, no material unexplained risk remains and any profile updates are completed. It may deepen when the customer explanation is incomplete, KYC is stale, ownership is unclear, external information conflicts with the profile, or key data is missing. It may widen when linked accounts, customers or counterparties reveal a network that changes the risk hypothesis. It may escalate when the evidence reaches the bank's local reporting threshold, indicates another specialist risk such as sanctions or fraud, or exceeds relationship risk appetite.

Those paths should be distinct in the case system. Escalated is not one outcome. Escalation can mean suspicious activity reporting review, sanctions/legal review, fraud intervention, customer risk re-rating, EDD, account restriction, exit consideration, law-enforcement liaison or control remediation. The owners and legal bases differ.

15. Suspicion and relationship decisions are related but different

A customer can be reported to an FIU while the account remains open, depending on applicable law, bank policy and law-enforcement considerations. A relationship can be restricted or exited because risk appetite is exceeded even when the legal suspicious-reporting threshold has not been met. A payment can be blocked under sanctions law independently of an AML suspicion decision. A fraud team can protect a victim or attempt recovery while AML evaluates the recipient account.

The review should therefore feed several decision domains without collapsing them. A practical case model can capture a suspicious activity decision, customer-risk decision, KYC/EDD action, account or product action, sanctions or legal restraint, fraud/customer-protection action and control-remediation action separately.

This separation is particularly important for automated workflow. A developer should not encode SAR filed = account closed or high risk = suspicious. Those shortcuts create legal, conduct and customer-harm risks. Decision dependencies should be explicit and jurisdiction-aware.

16. Data lineage determines whether the review can be trusted

Investigators usually work from a consolidated case screen, but the evidence may originate in dozens of systems. Customer data can come from onboarding platforms and master-data stores. Account details may come from core banking. Transactions may flow from payment hubs, card processors, cash systems, trade platforms, securities systems or data warehouses. Counterparty names may be customer-entered, message-derived or enriched. Risk scores may be calculated in separate engines. Device and fraud intelligence can come from digital channels.

The case should preserve enough lineage to answer: where did this field come from, when was it effective, was it transformed, and can the source record be reconstructed? A counterparty name normalised by a matching engine is useful, but investigators should still be able to see the original value. A country derived from an IBAN or bank identifier should be distinguishable from a declared address. An ownership relationship imported from a third-party data provider should show its source and freshness.

Point-in-time reconstruction is especially important. If a transaction was screened or investigated on 1 March, a later customer update should not silently rewrite what the investigator appeared to know on that date. Versioning, effective dating and immutable case evidence support both investigation quality and later audit.

17. Entity resolution is helpful and dangerous

Entity resolution tries to determine whether records that look different represent the same person or organisation. It can combine names, addresses, account identifiers, registration numbers, dates of birth, directors, beneficial owners, phone numbers, email addresses, devices, IP addresses and other attributes.

The benefit is clear: ABC Trading Ltd, A.B.C. Trading Limited and a local-language variant may be one company. Without normalization, repeated exposure can look fragmented. The danger is false linkage. Common names, shared office addresses, recycled phone numbers or household devices can link unrelated parties.

A good design therefore stores both the match result and the match evidence. High-confidence deterministic identifiers such as a verified company registration number may support automatic consolidation. Fuzzy name and address similarity should usually remain reviewable. Analysts need a way to split incorrectly merged entities and record why.

For business analysts and architects, this means entity resolution is not merely a search feature. It changes investigation scope and potentially customer outcomes. Model governance, threshold testing, false-link analysis and override controls are therefore part of the financial-crime control framework.

18. Quality assurance should test reasoning, not note length

A long case can still be poor. Quality assurance should ask whether the investigator scoped the right relationship, used current and point-in-time customer information, traced relevant accounts, identified material counterparties, tested plausible explanations, used external information appropriately, distinguished facts from inference, followed local escalation rules and recorded the rationale clearly.

Sampling should include both escalated and non-escalated cases. Reviewing only reported cases tests whether analysts can write suspicion narratives; it does not test whether cases are being closed too easily. QA should also examine cases from different products, customer types, risk segments and investigators to detect systemic weaknesses.

Calibration helps when judgement varies. Teams can review the same anonymised case and compare decisions, not to force absolute uniformity but to expose differences in interpretation. If one group consistently ignores counterparties or another treats high-risk geography as decisive, procedures or training may need adjustment.

Root-cause analysis should turn findings into control improvements. A repeated missed counterparty might reflect poor analyst training, but it might instead show that payment data is truncated, account linking is incomplete, entity resolution is weak or the case UI hides relevant information. The remediation owner should match the actual cause.

19. Management information should show risk movement

Case volumes and closure rates are operationally useful but insufficient. Leadership also needs to understand ageing, high-risk cases, data gaps, repeated customer-profile defects, unresolved ownership issues, network investigations, requests for information, escalation outcomes, QA defects, rework, customer impact and root causes.

For example, a growing queue of cases delayed by missing historical KYC may indicate a data-retention problem rather than an investigator-capacity problem. A sudden increase in cases involving one counterparty can be intelligence worth sharing with fraud or monitoring teams. Repeated closures followed by later SAR/STR escalation may indicate weak first-line investigation criteria.

MI should therefore support decisions: add capacity, repair data, tune scenarios, improve account linking, strengthen KYC, change a customer journey, update procedures or escalate risk acceptance. A dashboard that only shows opened / closed / pending cannot perform that governance function.

20. Delivery requirements for business analysts and architects

A strong set of requirements for this capability should make the review reproducible. The system should identify the customer and all in-scope accounts; show the relevant historical customer profile; expose ownership, control and authority relationships; provide transaction history with source and transformation lineage; support counterparty aggregation and normalization; preserve original payment values; allow linked-case and network views; record external-source evidence; support targeted RFIs; capture separate investigation and relationship decisions; and retain the evidence trail.

Requirements should also define failure behaviour. What happens if a customer master service is unavailable? Can the investigator see that a transaction feed is incomplete? Does the system prevent closure when required evidence is missing? Are late-arriving transactions added to the case automatically or flagged for review? Can a corrected identity record alter an already closed case without leaving history? What happens if two customer records are merged or split after the investigation?

Access control matters because customer and investigation data is sensitive. A relationship manager may need enough information to answer a factual question without seeing confidential suspicion details. A fraud analyst may need to share beneficiary intelligence without receiving the full AML file. The architecture should support role-based access and controlled cross-team hand-offs.

21. Testing should prove the difficult cases, not only the happy path

Positive testing should demonstrate that a genuine multi-account pattern can be reconstructed: funds arrive into one account, move internally, then leave through another product; the investigator sees one economic flow rather than disconnected events. A linked-customer test should show that common ownership or authority is visible without wrongly merging unrelated customers.

Negative testing should prove that ordinary activity is not automatically escalated. A corporate customer with many counterparties, a family sharing an address, a business using a co-working location, a customer changing device, or a high-volume merchant can all be legitimate. The test should verify that the system presents context rather than simply generating risk labels.

Temporal testing is critical. Change the customer's occupation, address, risk rating, owner or expected turnover after the transaction date and verify that the historical case still shows what was known at the relevant time. Test backdated corrections and late-arriving data separately.

Entity-resolution testing should include spelling variants, transliteration, common names, shared registered-agent addresses, reused telephone numbers, joint devices, subsidiaries and unrelated entities with similar names. Test both false negatives and false positives.

Data-quality testing should remove fields, duplicate transactions, truncate names, corrupt dates, break account links and delay feeds. The workflow should make uncertainty visible instead of silently producing a complete-looking case.

22. Common failure modes

The most common failure is single-account tunnel vision: the analyst reviews only the triggered account even though related products materially change the pattern. Another is current-profile bias, where today's KYC is used to explain historic activity. Counterparty blindness occurs when the bank summarises debit and credit totals but never asks who is repeatedly on the other side. Graph overreach is the opposite problem: weak data links are treated as proof of association.

Other failures include double-counting internal transfers; relying on unverified counterparty names; accepting customer explanations without corroboration; treating lack of adverse media as evidence of legitimacy; treating adverse media allegations as proven facts; using high-risk geography as an automatic suspicion decision; failing to preserve source data; allowing case notes to mix fact and inference; and closing cases while required feeds or documents are missing.

Operational pressure makes these weaknesses worse. When queues grow, analysts may shorten review windows, skip linked-account searches or accept stale KYC simply to meet service levels. Governance should therefore monitor whether backlog pressure is changing investigation scope or quality, not just whether cases are ageing.

23. Mini case study: the importer whose activity no longer fits one account

A medium-sized electronics importer has banked with the institution for four years. The customer profile says it purchases components from established suppliers in East Asia and sells finished products domestically. Two directors own the company equally. Expected activity includes overseas supplier payments, domestic wholesale receipts, payroll and tax payments. The relationship has a current account and a foreign-currency account.

A monitoring alert fires because the current account receives a cluster of third-party credits from more than forty individuals over three weeks, followed by same-day transfers to the foreign-currency account and onward payments to two companies in another jurisdiction. Looking only at the current account, the pattern resembles rapid pass-through activity. Looking only at the foreign-currency account, the payments resemble supplier settlements.

The investigator first reconstructs the point-in-time profile. There was no declared retail marketplace activity and no recent KYC event showing a change in business. The two overseas beneficiaries are new. Company-registry checks show that one beneficiary is an electronics wholesaler, while the second describes itself as a consulting company. Neither appears in the historical supplier list. The consulting company shares a director with a logistics firm that has previously received payments from another customer under review. That link is recorded as a fact; it is not yet treated as proof of common criminal control.

The analyst groups the forty incoming credits and finds that most contain references suggesting consumer electronics purchases. That creates a plausible legitimate hypothesis: the importer may have launched a direct-to-consumer sales channel without updating its profile. The investigator asks the relationship team for evidence of the business change and requests targeted documentation from the customer under approved procedures.

The customer provides an e-commerce platform agreement and sales records that explain most incoming credits. However, the second overseas beneficiary is described as a marketing consultant, while invoices show unusually large fees that consume a significant share of the new retail revenue. The company cannot explain why the consultant receives funds through a jurisdiction unrelated to the marketing service, and the invoice descriptions are generic. Further review identifies repeated onward transfers from that beneficiary to an entity linked to one of the customer's directors, based on information available to the bank through another relationship.

At that point the investigation hypothesis changes. The consumer receipts themselves may be legitimate, but part of the onward flow may represent undisclosed related-party movement or another form of misuse. The case is widened to include the linked relationship, subject to access and confidentiality controls. The customer profile is marked for event-driven review because the business model has changed. The unresolved flows are escalated under the bank's local suspicious-activity decision process. Whether an STR/SAR is filed, whether the relationship is restricted, and whether further customer contact is permitted are decided separately under applicable law and policy.

The lesson is that no single red flag solved the case. The outcome came from reconciling customer purpose, multi-account flow, counterparty identity, ownership links, point-in-time information and corroborating evidence.

24. What good review looks like

A good customer, account and counterparty review can be explained without relying on the investigator's memory. It identifies the relevant customer and relationship, reconstructs what the bank knew at the time, follows value across material accounts and products, identifies the counterparties that matter, tests plausible explanations, records evidence provenance, distinguishes fact from inference, and makes uncertainty visible.

It is also proportionate. It does not build an enormous network because one payment is unusual. It does not treat every higher-risk country or sector as suspicious. It does not make a relationship decision simply because a report is filed. And it does not assume that an automated graph, risk score or data provider can replace human judgement.

For compliance teams, the control connects ongoing CDD to investigation. For operations, it defines what must be reviewed and escalated. For architects and developers, it creates requirements for historical data, account linking, entity resolution, lineage and case workflow. For testers, it creates meaningful scenarios around multi-account behaviour, stale data, false links and late information. For product owners, it clarifies where customer friction is justified and where better data can reduce unnecessary friction.

The professional standard is simple: understand the relationship before judging the activity. A transaction is only one event. Financial-crime risk usually makes sense when customer, accounts and counterparties are seen as one evidence-based story.

Key takeaways

Customer review establishes who the bank believes it serves and what use was expected. Account review establishes how the relationship was actually used across products and time. Counterparty review establishes who repeatedly sits on the other side of value and whether those relationships make economic sense. The investigation becomes defensible when those views are reconciled using point-in-time data, reliable entity links, documented evidence and proportionate judgement.

Global standards such as FATF define the control objective, while local law determines reporting tests, deadlines, confidentiality rules and permitted account actions. Systems should therefore preserve both universal investigation principles and jurisdiction-specific decision logic.

Most importantly, the review must remain evidence-led. A risk score, red flag, network link or unusual geography can tell the investigator where to look. None of them should decide the case by itself.

Operational deep dive: reconstructing a relationship as evidence

The base chapter established the three-lens model: customer, account and counterparty. This deep dive focuses on the investigation craft needed to make those lenses work together. The central idea is that a relationship review is not a larger transaction search. It is a reconstruction exercise. The investigator is trying to understand what the bank knew, what the customer did, who was involved, how the observed activity relates to the declared purpose of the relationship, and which facts remain unexplained.

That distinction matters because the same data can support very different conclusions depending on context. Fifty incoming credits may be ordinary for a marketplace seller and unusual for a salaried employee. A company paying three overseas suppliers may fit its business model, while the same company receiving large payments from unrelated consumers may not. A counterparty incorporated in a higher-risk jurisdiction can be perfectly legitimate, while an apparently low-risk domestic counterparty may hide common ownership or onward movement. Investigation quality comes from combining evidence rather than counting risk indicators.

1. Build a point-in-time customer snapshot before analysing behaviour

Before analysing transactions, establish the customer profile that applied during the activity under review. This should be a reproducible snapshot rather than a copy of today's KYC screen.

For an individual, the snapshot may include legal identity, date of birth, residence, occupation, employer, expected income, account purpose, expected payment corridors, source-of-funds information where relevant, customer risk rating and previous review dates. For a legal entity, it may include legal form, incorporation details, registered and operating addresses, industry, expected turnover, ownership and control, directors, authorised signatories, principal customers and suppliers, countries of operation, source of capital, products held and expected transaction profile.

The investigator should identify which facts were verified, which were customer-declared, which were derived by the bank, and which came from third parties. Those categories are not interchangeable. A verified company-registration number has a different evidential status from a free-text business description. A country inferred from an IBAN is not the same as a verified operating address. A commercial data provider's beneficial-owner record may be useful but needs freshness and source context.

The snapshot should also include material changes. If a beneficial owner changed three months before the alert, the earlier owner may still matter to older activity. If a customer changed occupation after a series of unusual payments, the later occupation cannot be used automatically to explain them. If KYC remediation corrected a misspelled name or missing nationality, the case should preserve both the original record and the correction so a reviewer can understand what the bank knew at the time.

This temporal discipline is particularly important in enforcement or audit reviews. A case that looks well supported using today's data may have been poorly understood when the decision was made. Conversely, a historical case should not be criticised merely because later information became available. The evidence set needs a clear as-of date.

2. Define the account perimeter deliberately

The next step is to decide which accounts and products belong inside the review. The customer master is the natural starting point, but the investigator should test whether the relationship extends beyond one record.

A retail relationship may include current accounts, savings accounts, cards, loans, investment products and digital wallets. A corporate relationship may include multiple current accounts, foreign-currency accounts, cash-management structures, trade-finance facilities, merchant acquiring, cards, deposits, treasury products or accounts held by related legal entities. A correspondent or financial-institution relationship may require a different perimeter again because the direct customer's activity can represent underlying clients.

The account perimeter should be broad enough to explain the economic flow but no broader than necessary. Adding every group company because it shares a brand name can create noise. Excluding a personal account controlled by the same owner when it repeatedly funds the business can hide material activity. The decision should be based on observed links, legal relationship, control, authority and case hypothesis.

The system should display why an account is linked: same customer identifier, same beneficial owner, joint holder, authorised signatory, group relationship, internal transfer pattern, shared verified contact detail or another reason. An unexplained linked account badge is not sufficient for investigative use.

3. Reconstruct value without double-counting it

A common analytical error is to total every debit and credit without distinguishing external value from internal movement. If 100,000 enters Account A, moves to Account B, is converted to foreign currency, and leaves Account C, a naive dashboard may show several hundred thousand of turnover even though the economic flow involved one 100,000 inflow and one onward disposition.

Investigators should identify internal transfers and ownership-related movements so they can trace value through the bank without double-counting it. The original inflow and final external destination usually matter more than the internal routing, although the routing itself can still be relevant. Repeated movement through several internal products may indicate ordinary treasury management, currency conversion, liquidity management or deliberate layering depending on context.

A useful flow reconstruction records:

• origin or source category;
• first in-scope account receiving value;
• internal movements and transformations such as FX;
• final external destination or use;
• elapsed time between stages;
• amount retained, spent, withdrawn or returned;
• associated counterparties and identifiers;
• transaction or message references that link the stages.

For payment investigations, reference fields can help connect events across systems. End-to-end references, UETRs, account-servicer references, card transaction identifiers, merchant IDs, trade references and internal booking IDs each provide different linkage value. The investigator should know whether an identifier is globally unique, locally unique, recycled, transformed or absent on some rails.

4. Analyse behaviour in windows, not only totals

Aggregate totals are useful for scale but often hide timing. The same monthly turnover can represent stable business receipts or a burst of rapid pass-through activity concentrated in two days.

Time-window analysis should therefore look at daily and weekly patterns, first and last activity, changes from baseline, inactivity, dormancy and reactivation. Useful measures may include the percentage of incoming value moved out within 24 or 48 hours, the number of new counterparties in a period, the concentration of value among top counterparties, cash-to-non-cash ratios, cross-border share, weekend or out-of-hours activity, and repeated sequencing patterns.

These measures are descriptive, not universal suspicion thresholds. A payment institution, payroll provider or treasury centre may legitimately move most funds quickly. A retailer may have strong seasonal spikes. A customer changing jobs may suddenly receive a different salary source. The measure tells the investigator where the behaviour differs; the customer and counterparty context explains whether the difference matters.

5. Create a counterparty inventory before building a network

For complex cases, a simple counterparty inventory can be more useful than an immediate graph. The inventory should consolidate parties that appear to be the same while preserving the original transaction data.

Useful fields include counterparty display name, normalized name, account or wallet identifier, institution, country indicators, first seen, last seen, number of transactions, total incoming value, total outgoing value, maximum single amount, payment references, stated or inferred relationship, verification status and any internal-customer linkage.

The inventory makes concentration visible. It can show that ninety apparently unrelated transactions actually go to three recurring beneficiaries, or that a customer receives value from hundreds of individuals but sends funds to one aggregator. It can reveal that a counterparty thought to be new has appeared under a spelling variant for years.

Normalization must remain transparent. The investigator should be able to expand a consolidated party and see the raw names and identifiers that were grouped. If a fuzzy algorithm merged records, the match confidence and features should be available. Silent normalization can create false certainty.

6. Distinguish counterparty identity from counterparty relationship

Knowing who the counterparty is does not automatically explain why the customer transacts with them. The review should try to establish the relationship where it is material to the case.

For a corporate customer, a counterparty may be a supplier, customer, parent, subsidiary, affiliate, broker, agent, freight forwarder, tax authority, employee, lender or service provider. For an individual, it may be an employer, family member, landlord, merchant, lender, investment platform, remittance recipient or peer. The same named party can fulfil different roles over time.

The relationship should be supported by evidence proportionate to risk. A payment narrative alone may be weak. Repeated payroll-pattern transfers may support an employer relationship. Company registries may support group ownership. Contracts, invoices, shipping documents or public business information can support commercial relationships. Customer statements can be relevant but may require corroboration when risk is elevated.

The investigator should avoid manufacturing precision. If the evidence establishes only that two parties repeatedly transact, record that. Do not label them supplier merely because the customer used that word once.

7. Use ownership and control as network dimensions

Payment networks and ownership networks answer different questions. A customer may never directly transact with the beneficial owner of a counterparty, yet common ownership can explain why value moves between companies. Conversely, two companies can transact heavily without any shared ownership.

For legal entities, the review should be able to trace the ownership/control chain relevant to the risk question. This does not require an investigator to reproduce a full corporate tree for every case. It means understanding enough to detect hidden related-party transactions, unexpected controllers, nominee structures or changes that alter the apparent independence of counterparties.

FATF's Recommendation 24 guidance on legal persons and Recommendation 25 guidance on legal arrangements are useful global references for why adequate, accurate and up-to-date beneficial ownership information matters. They do not prescribe one bank investigation method. Institutions implement the relevant CDD and verification duties under local law and policy.

Where ownership data conflicts across sources, the conflict should be visible. Registry information, customer declarations, shareholder documents and commercial databases may not align. The investigator should record which source is considered authoritative for which fact and whether the discrepancy itself is relevant.

8. Treat shared attributes with different evidential weights

Network analysis often uses shared addresses, phone numbers, email addresses, devices, IP addresses, directors or authorised users. These links can be useful but they are not equally strong.

A verified unique company-registration number is usually a strong identity signal. A common office address can be weak because thousands of companies may use the same registered agent or co-working site. A device shared between two retail customers could indicate family use, fraud, a public device or criminal coordination. A phone number can be recycled. An IP address may represent an entire corporate network or mobile carrier gateway.

The case platform should therefore avoid a single generic link strength that obscures why the link exists. Investigators need the underlying attributes and dates. A device association that occurred once two years ago is different from repeated simultaneous use around suspicious transactions.

Good analysts ask: what innocent explanation could create this link, and what additional evidence would distinguish it from the risky explanation? That question prevents a graph from becoming a confirmation-bias machine.

9. Follow the strongest unexplained feature

Complex cases can produce dozens of anomalies. Trying to investigate every one equally wastes time and dilutes the core question. The analyst should identify the features that most materially change the risk assessment.

For example, a customer's turnover may be higher than expected, several counterparties may be new, and one beneficiary may be located in a higher-risk jurisdiction. Those are relevant. But if the strongest unexplained fact is that most incoming value comes from unrelated individuals and is transferred within hours to a company controlled by the customer's director, that relationship should drive the investigation.

This does not mean ignoring other red flags. It means organising them around a coherent hypothesis. The case note should explain why particular evidence mattered rather than presenting a checklist of every possible indicator.

10. Challenge the customer profile and let the profile change

Ongoing due diligence is not a one-way process in which KYC informs monitoring. Monitoring should also inform KYC. If observed behaviour shows a legitimate new business model, new countries, new products or changed source of funds, the customer profile should be reviewed and updated through the appropriate process.

AUSTRAC's current 2026 ongoing CDD guidance makes this feedback loop explicit in the Australian context: businesses are expected to monitor customer transactions and behaviour, identify unusual activity, review and where appropriate update customer risk and KYC information, and document their monitoring processes. The FFIEC manual similarly describes U.S. ongoing monitoring as risk-based and event-driven. The FCA's current Financial Crime Guide describes UK ongoing monitoring as scrutinising transactions for consistency with customer knowledge and keeping CDD information current.

The exact legal duties differ, but the operational lesson is consistent: a customer profile that never changes when behaviour changes is not a useful control input.

11. Evaluate requests for information as part of evidence quality

An RFI should close a specific evidential gap. Before sending it, the analyst should record what is unknown and what a satisfactory response would look like.

Suppose the case shows repeated payments to a new overseas consultancy. The gap is not simply need invoice. The investigator may need to understand the service provided, why that counterparty was selected, how fees were calculated, who owns the consultancy, and why payments are routed through a particular jurisdiction. The documentation requested should match those questions.

Responses should be tested against bank data. If the customer says the payments relate to twelve monthly consulting invoices but the transaction pattern consists of forty irregular round-value payments, the discrepancy matters. If the customer supplies invoices created after the bank's RFI, document dates may need explanation. If a contract names one entity but payments go to another, the relationship needs to be established.

The bank should also consider customer harm and confidentiality. Questions should be no broader than necessary and should follow local rules on tipping-off, privacy and bank secrecy. The analyst should not disclose confidential intelligence merely to obtain an answer faster.

12. Negative evidence is part of a defensible conclusion

Investigations should record material facts that weaken the suspicion hypothesis as well as facts that strengthen it. This is especially important in network cases because graph visualisations naturally draw attention to connections.

Negative evidence can include verified separation of beneficial ownership, documented commercial purpose, long-standing transaction history consistent with the business, independently confirmed licensing, payment references consistent with underlying contracts, or evidence that a shared address is a professional registered office used by many unrelated entities.

Recording such evidence does not mean the case must close. It means the judgement is balanced. If an escalation later occurs, the decision-maker can see which innocent explanations were considered and why concern remained.

13. Use point-in-time external sources where possible

External information often reflects the present, while the transaction under review occurred in the past. A registry may show today's directors, not the directors at the time of the payment. A website may have changed. A licence may have been issued or revoked after the activity.

Where historical records are available, use them. Where they are not, state the limitation. Registry accessed 20 September 2026 shows X as current director; historical directorship at transaction date not independently verified is more accurate than implying the director relationship existed throughout the period.

This discipline is particularly important when external information drives network expansion. An ownership connection discovered today should not automatically be projected backwards without evidence.

14. Counterparty due diligence is not always customer due diligence

A bank generally has a direct CDD relationship with its customer. It may have much less information about an external counterparty. Investigators must work within that visibility difference.

It can be tempting to require the same data set for every counterparty as for a customer, but that may be impossible and unnecessary. The bank may know only the counterparty name, account identifier, institution, country and remittance information. In higher-risk cases it may supplement this with public or commercial information. If the counterparty is also a customer of the same institution, access to additional data must still respect internal confidentiality, need-to-know rules and legal restrictions.

The case should therefore mark whether a party is a bank customer, an external counterparty, a customer of another group entity, a merchant, a correspondent respondent, an ultimate party or another role. Role clarity prevents assumptions about what the bank has actually verified.

15. Preserve the original payment record alongside enrichment

Investigation platforms often enrich transactions with normalized names, geolocation, risk scores, entity matches, sanctions results or customer labels. Enrichment is useful, but the original message or booking record should remain reconstructable.

For an ISO 20022 payment, for example, the investigator may see structured debtor and creditor fields, ultimate parties, agents, remittance information and purpose codes. Some fields may have been mapped from another format, truncated upstream or enriched internally. If the case relies on a counterparty name or country, the analyst should be able to determine whether it came from the original message, customer master, account identifier, screening engine or another source.

This is a data-lineage requirement as much as an investigation requirement. A later dispute or audit may depend on what the bank actually received rather than what a downstream interface displayed after enrichment.

16. Review chronology before writing the conclusion

Before deciding the case, build a short chronology of material events. This often reveals relationships that are hard to see in static tables.

A chronology might show:

1. customer onboarded with domestic business model;
2. new director appointed;
3. foreign-currency account opened;
4. first payments from unrelated individuals received;
5. new beneficiary created;
6. rapid outbound transfers begin;
7. first monitoring alert closes with limited scope;
8. adverse information appears;
9. current case triggered;
10. customer explanation obtained;
11. linked account or counterparty identified.

The chronology helps the investigator ask causal questions: did the behaviour change after ownership changed? Did an alert precede KYC refresh? Did the bank already hold information that should have altered risk earlier? Were repeated cases fragmented across teams?

17. Decide whether the unexplained activity is material

Not every unexplained transaction requires escalation. The investigator should assess materiality in context: amount, frequency, pattern, relationship to known risks, proportion of the customer's activity, persistence, counterparty significance and whether the unexplained feature changes the overall risk story.

A single small payment with a vague narrative may remain unexplained but immaterial after review. A small payment can still be highly material if it links the customer to a designated or criminal network, a fraud victim cluster or a prohibited activity. Materiality is therefore not purely monetary.

The decision rationale should identify which unexplained facts were material and why. This makes the case easier for a second-line reviewer to challenge.

18. Keep reporting logic jurisdiction-specific

FATF Recommendation 20 sets the global expectation for prompt reporting to the FIU where the institution suspects or has reasonable grounds to suspect criminal proceeds or terrorist financing. It does not create one universal threshold phrase, deadline or form.

A multinational bank should therefore route a completed relationship review into a jurisdiction-specific decision service or procedure. That procedure should determine the applicable legal entity, FIU, reporting test, timeline, confidentiality requirement, consent or defence regime where applicable, and any interaction with account or payment decisions.

The investigation record should not hard-code local concepts as global ones. SMR, SAR, STR and other report names are jurisdictional labels. A global case model can capture the generic concept of suspicious activity reporting while local workflows implement the legal details.

19. The review should improve upstream controls

A closed investigation is still useful if it reveals control information. New counterparty patterns can inform monitoring. Customer-profile gaps can improve onboarding. False entity links can improve matching. Repeated missing payment fields can trigger data remediation. Legitimate new business models can refine peer groups so similar customers generate fewer unnecessary alerts.

Wolfsberg's 2024 and 2025 statements on effective monitoring for suspicious activity are relevant industry guidance here. They describe monitoring more broadly than traditional transaction monitoring, recognising the value of customer behaviour and attributes alongside transactions and encouraging institutions to focus on effective outcomes. That is not law, but it reinforces a practical direction: investigations should generate intelligence that improves the monitoring ecosystem rather than operate as a one-way case-closure factory.

20. Review outcome template

A concise but complete relationship-review conclusion can answer six questions in order:

Who is the customer and what was expected? State the relevant point-in-time profile and material ownership/control facts.

What actually happened? Summarise the account and transaction pattern across relevant products without double-counting internal movement.

Who were the material counterparties? Identify the parties that drove the risk assessment and the evidence supporting their identities or relationships.

What explanations were tested? Record customer explanations, independent evidence, contradictions and negative evidence.

What remains unexplained and why does it matter? Separate unresolved facts from inferred risk.

What happens next? Record closure, KYC update, deeper review, network expansion, reporting escalation, specialist hand-off, relationship action or control remediation as separate outcomes.

That structure keeps the conclusion focused on reasoning rather than note volume. A reviewer who can answer those six questions should be able to understand the case without replaying every analyst click.

Advanced practice: architecture, testing and assurance for relationship review

A relationship review can be excellent on paper and still fail in production because the case platform cannot reconstruct historical KYC, account links are incomplete, counterparty normalization merges the wrong entities, or analysts cannot see that a data feed is late. Advanced practice therefore treats customer, account and counterparty review as a joined operational and technology capability.

The objective is not to automate judgement. It is to make the evidence set complete enough, transparent enough and time-aware enough that a trained investigator can make a defensible judgement and another reviewer can reproduce it later.

1. Define the canonical investigation entities

The data model should distinguish at least the customer, legal entity, natural person, account, product, transaction, counterparty, external institution, device or channel identifier where relevant, ownership/control relationship, case, alert and evidence item. These objects need stable identifiers and effective dates.

A party abstraction can be useful technically, but the investigation interface still needs roles. The same party can be the bank's customer in one transaction, an external creditor in another, a beneficial owner of a third entity, and an authorised signatory on another account. Role is therefore contextual, not a permanent attribute.

Requirements should also distinguish the bank customer identifier from account identifiers and from external counterparty identifiers. When a counterparty is also a customer of the bank, the linkage should be made through controlled entity resolution rather than a simple name match. The investigator should know whether the link is deterministic, probabilistic or manually confirmed.

2. Make temporal data first-class

A financial-crime platform should not behave as though customer data has one eternal value. For every risk-relevant field, business analysts should ask whether the system needs the current value, the historical value, or both.

Examples include legal name, address, occupation, business activity, directors, beneficial owners, authorised users, country exposure, expected turnover, expected transaction type, risk rating and product holdings. An effective-date model can use validFrom and validTo, source-system timestamps or version identifiers. The exact implementation varies, but the investigator must be able to reconstruct the profile applicable to the review period.

Testing should prove that later changes do not overwrite historic evidence. Create a customer with one occupation or ownership structure, post transactions, change the profile, open a case and verify that the investigator can see both the current state and the point-in-time state. Then backdate a correction and verify that audit history remains visible.

3. Design account linking with explainable reasons

A case platform often presents an all customer accounts view. That feature is only reliable if the linkage logic is governed.

Deterministic links can include a common customer master ID, verified joint-holder relationship or recorded legal-entity ownership. Probabilistic or inferred links can include common contact details, devices, addresses or transaction behaviour. These should not be presented with the same certainty.

A useful interface shows the linked account, link type, source, effective dates and confidence where applicable. Analysts should be able to reject an erroneous inferred link without corrupting the source record. Overrides should be logged and, where repeated false links occur, fed back into matching governance.

Testing should include duplicate customer records, merged records, split records, joint accounts, group companies, closed accounts, migrated accounts and accounts held in legacy platforms. A customer migration is a particularly important scenario because a new identifier can make the historical relationship appear to start on the migration date unless mapping tables are preserved.

4. Preserve payment-party roles

Counterparty analysis becomes unreliable when payment data is flattened into payer and payee regardless of rail. ISO 20022 can carry debtor, creditor, ultimate debtor, ultimate creditor and multiple agents. Card records can identify merchant, acquirer and cardholder. Trade transactions can contain applicant, beneficiary, issuing bank, advising bank, carrier and other documentary parties. Cash can have no meaningful external counterparty at all.

The investigation model should preserve the roles supplied by the source and avoid presenting derived roles as original facts. If the bank creates a normalized counterparty object, it should retain links back to the raw message or transaction record.

For business analysts, a good requirement is: For every displayed counterparty relationship, the investigator shall be able to identify the source transaction, original party role, original source value, normalization applied and any entity-resolution decision used to consolidate it.

5. Entity-resolution acceptance criteria

Entity resolution needs explicit acceptance criteria because errors can materially change case scope.

Positive tests should include legal-name abbreviations, punctuation variation, transliteration, common corporate suffixes, known aliases and verified identifiers. Negative tests should include common surnames, unrelated companies at the same registered-agent address, family members sharing an address, customers on the same corporate network, recycled telephone numbers and similar company names with different registration numbers.

Threshold testing should measure both missed links and false links. A system tuned only for recall can create enormous noisy networks. A system tuned only for precision can miss the relationships investigators need. Different use cases may justify different thresholds: a search-assist function can tolerate more candidate links than an automatic account-consolidation function that changes the evidence set.

Human-confirmed links should be stored separately from algorithmic suggestions. If a later model version changes the score, the original case should still show what the analyst saw and confirmed at the time.

6. Data-completeness gates

The case should not look complete when critical feeds are missing. Data-health metadata should be visible to the investigator.

Examples include transaction-feed coverage dates, latest KYC synchronization timestamp, missing product feeds, failed enrichment services, unavailable external data or incomplete historic records. The workflow may allow the analyst to continue, but the limitation should be explicit and closure rules should reflect materiality.

A useful control is a completeness gate that checks whether all mandatory data sources for the selected case type have loaded. If a source is unavailable, the system can require an exception reason or supervisor approval before closure. This is stronger than relying on analysts to remember which screens should contain data.

Failure-mode testing should deliberately stop a transaction feed, delay a customer-master update, remove ownership data and make an enrichment API unavailable. Verify that the platform surfaces the problem, prevents false certainty and records how the investigator proceeded.

7. Transaction deduplication and internal-transfer handling

Data warehouses can duplicate transactions during replay, migration or multi-source ingestion. Investigations can also double-count the same economic event when a transaction appears in both payment and core-booking feeds.

Requirements should identify a canonical event and preserve source variants without summing them blindly. Deduplication rules should use stable transaction identifiers where available and controlled composite keys where they are not. Ambiguous duplicates should remain reviewable.

Internal transfers need separate treatment. The system should identify when value moved between accounts controlled by the same customer or related entity so investigators can follow the flow without inflating external turnover. However, the transfer should not disappear because the routing itself may be relevant.

Test partial reversals, returns, chargebacks, same-day internal transfers, FX legs, split postings and migration-generated duplicate IDs. These are the cases where naive turnover calculations become misleading.

8. Network graph design should expose evidence, not decorate it

A graph is useful only if the investigator can understand why two nodes are connected. Every edge should have a relationship type, source, relevant dates and, where appropriate, confidence.

The graph should allow filtering by relationship type and time. A customer may have shared an address with another party five years ago but not during the current case. A director link can have start and end dates. Payment relationships can be filtered to the investigation window.

Visual prominence should not imply suspicion. A large node might represent transaction volume, degree centrality or simply a selected object. The legend should say which. Risk colours should be based on defined attributes rather than aesthetic choices that make one party appear more criminal.

Accessibility also matters. Investigators using keyboard navigation or screen readers need a tabular alternative to the visual graph. Mobile or smaller-screen views should prioritise the top relevant relationships rather than compress an unreadable network.

9. Explainable counterparty scoring

Some banks score counterparties or network relationships to prioritise review. If scoring is used, investigators should see the material factors: for example first-seen status, transaction concentration, rapid pass-through association, known internal customer linkage, geography, adverse information or connection to existing cases.

The score should not be treated as a legal conclusion. It is a prioritisation aid. Model governance should document training data where applicable, feature definitions, exclusions, performance, drift, explainability and change control.

A counterparty score can also create feedback loops. Once a party is associated with several investigations, future activity may score higher, generating more cases and further reinforcing the score. Governance should distinguish independent risk evidence from prior internal suspicion so the model does not create self-confirming networks.

10. Case-screen requirements

A practical case screen for this topic should let the investigator move through the relationship without opening a dozen disconnected applications. Useful capabilities include:

• point-in-time customer profile with current-state comparison;
• ownership and control view with effective dates;
• consolidated accounts and products with link rationale;
• transaction explorer with raw and normalized counterparty data;
• internal-transfer identification;
• counterparty inventory and optional graph;
• previous alerts, cases and relevant internal referrals;
• external evidence capture with source and retrieval date;
• RFI workflow and response tracking;
• separate fields for facts, hypotheses, unresolved questions and decisions;
• data-completeness status and source lineage;
• separate reporting, customer, payment, KYC and remediation outcomes.

These are not all mandatory for every bank or case type. They illustrate the capabilities that reduce manual reconstruction and hidden evidence gaps.

11. Workflow controls for widening a case

When an investigator discovers a linked customer or counterparty, the system needs a controlled way to widen the investigation. Simply adding every linked party to one case can create access, ownership and service-level problems.

A widening action should record the reason, relationship, materiality and approval rule where relevant. It may create a linked case instead of extending the original. The parent and child cases should remain traceable. Deadlines and ownership should not be lost during the hand-off.

The workflow should also prevent silent scope reduction. If an analyst removes an account or linked party that was previously included, the reason should be recorded. This is especially important when queue pressure creates incentives to narrow cases.

12. Privacy, confidentiality and least privilege

Relationship review often brings together more personal information than ordinary servicing. Access should therefore be role-based and purpose-limited.

Investigators may need broad financial-crime data, while relationship managers may need only a targeted request. Fraud teams may share device or beneficiary intelligence without receiving confidential SAR/STR information. Group entities may face legal restrictions on cross-border data sharing. External data sources may have contractual or privacy limitations.

The platform should support segmented notes and evidence where required. Audit logs should record who viewed, exported or changed sensitive case information. Data retention should follow applicable legal and policy requirements rather than an indefinite keep everything approach.

13. Testing the balanced case

The strongest test cases include both suspicious-looking and innocent explanations. A useful corporate scenario might begin with rapid pass-through activity and a new overseas counterparty. One branch of the test supplies credible invoices, shipping evidence and a verified ownership structure consistent with the business. The correct outcome should be closure plus KYC update. Another branch introduces inconsistent invoices, unexplained related-party ownership and repeated onward movement. The correct outcome should be deeper review or escalation under local procedures.

This proves that the workflow supports judgement rather than simply rewarding the presence of red flags.

Retail testing can use a customer who suddenly receives many third-party payments. In one scenario the activity is a disclosed fundraising event or marketplace sale supported by evidence. In another it is a mule pattern with victim references, rapid dispersal and links to other flagged accounts. The system should present the evidence needed to distinguish the scenarios.

14. Historical-case regression testing

Whenever customer-master, payment, case-management or entity-resolution systems change, rerun historical cases whose correct outcomes are already understood. Verify that the new system reconstructs the same customer state, account set, key counterparties and material flow.

Differences are not automatically defects. A new system may legitimately improve linkage. But material differences should be explained and tested before deployment. This is particularly important when replacing a KYC platform or customer identifier because historical account linkage can silently break.

Regression packs should include cases with ownership changes, account migrations, multiple currencies, returns, closed accounts, shared identifiers, transliterated names, cross-product activity and late-arriving evidence.

15. Operational capacity and service levels

Deep relationship review consumes more analyst time than simple alert triage. Capacity planning should therefore account for case complexity, not only case count.

Useful workload attributes include number of accounts, transaction volume, number of material counterparties, corporate-ownership complexity, RFI dependency, external-research requirement, number of jurisdictions and network expansion. A team handling ten complex corporate network cases may have more risk exposure than a team handling hundreds of simple retail alerts.

Service levels should protect time-sensitive risks without turning ageing targets into pressure to reduce review scope. Management should monitor whether approaching deadlines correlate with narrower transaction windows, fewer counterparties reviewed or higher QA defects.

16. QA sampling strategy

Quality assurance should sample across closure and escalation outcomes, customer segments, products, analysts, case complexities and risk ratings. Purely random sampling can miss small but critical populations, so risk-based sampling should supplement it.

QA should test whether the case perimeter was appropriate, historical customer data was used correctly, material accounts were included, counterparties were resolved accurately, customer explanations were corroborated proportionately, negative evidence was considered, local reporting logic was applied correctly, and separate customer/reporting decisions were maintained.

Defects should be classified by cause. A missed counterparty caused by an analyst differs from one hidden by a broken mapping. A wrong historical owner caused by an overwrite defect requires system remediation, not merely retraining.

17. Metrics that indicate control health

Operational metrics can include case ageing, median and tail review time, RFI response time, reopened cases and backlog. Control-health metrics should go further.

Examples include the percentage of cases with point-in-time KYC available, percentage with incomplete source feeds, rate of entity-link overrides, proportion of cases widened to linked accounts, counterparty-resolution error rate, QA defects by root cause, customer-profile updates triggered by investigations, repeated alerts after closure, and cases where later intelligence materially changed an earlier decision.

No single metric proves effectiveness. The purpose is to identify where the control is losing information or consistency.

18. Change control when a payment rail migrates

A move from one payment format or rail to another can change counterparty visibility. Structured ISO 20022 fields may provide richer party information than legacy formats, but mapping and truncation can still degrade data. A new instant-payment rail may compress the time available for pre-payment decisions while improving structured identifiers. A card-processor migration may change merchant descriptors or transaction IDs.

Change impact assessment should identify which investigation fields are sourced from the old and new rail, how roles map, whether identifiers remain stable, whether historical searches span both systems, and how counterparty normalization behaves across formats.

Parallel-run testing should compare the old and new evidence view for the same transactions where possible. Data-quality tolerances should be defined before migration, not after investigators notice missing counterparties.

19. Outsourcing does not outsource accountability

Banks may use external vendors for KYC data, adverse-media screening, entity resolution, graph analytics or investigation support. The bank still needs to understand how material evidence is produced and how vendor changes affect the control.

Contracts and governance should cover data provenance, update frequency, model or matching changes, service availability, error correction, audit access and data-retention requirements. Investigators should not receive a vendor risk label with no explanation when that label materially drives the case.

Vendor outages should have documented fallbacks. If a registry or entity-link service is unavailable, the case platform should show the limitation and define whether review can proceed, needs manual alternatives or must wait.

20. A practical acceptance-criteria set

For a release affecting this capability, a product owner could require that:

1. the investigator can retrieve current and point-in-time customer profiles for the full supported retention period;
2. all in-scope accounts are linked through a documented customer or relationship key;
3. every account link exposes its rationale and source;
4. internal transfers are identifiable without deleting them from the transaction history;
5. original counterparty values remain visible after normalization;
6. entity-resolution suggestions show the attributes used and can be accepted or rejected;
7. material source-feed gaps are visible before case closure;
8. external evidence stores source and retrieval date;
9. case widening and scope reduction are auditable;
10. reporting, customer, payment, KYC and control-remediation outcomes are recorded separately;
11. role-based access prevents unnecessary disclosure of confidential investigation information;
12. regression tests prove historical cases remain reconstructable after migration.

These criteria translate a broad financial-crime control objective into behaviour that architects, developers, testers, operations and compliance can verify together.

21. Assurance conclusion

The control is effective only if it can reconstruct a relationship reliably under real operating conditions. That means historical data survives change, accounts can be linked without hiding uncertainty, counterparties can be normalized without inventing relationships, raw evidence remains traceable, data gaps are visible, and workflow decisions remain jurisdiction-aware.

Technology should make the investigator's reasoning easier to test, not harder to understand. The strongest implementation is therefore not the one with the most data or the most impressive network graph. It is the one in which a competent reviewer can answer, with evidence, who the bank served, how the relationship was used, who received or supplied value, what was known at the relevant time, and why the final decision was reasonable.

References and further reading

These sources support the global standards and jurisdiction-specific examples used in this chapter. FATF and Basel material provides the global or international control context. FCA, FFIEC/FinCEN and AUSTRAC material illustrates how particular jurisdictions translate ongoing customer due diligence, monitoring and investigation expectations into supervisory practice. Local law, the bank's legal entity and approved policy remain controlling for legal thresholds, reporting duties, confidentiality, retention and customer actions.

Global standards and international guidance

• FATF Recommendations — Recommendation 10 covers customer due diligence, beneficial ownership, purpose and intended nature of the relationship, and ongoing scrutiny of transactions against the institution's knowledge of the customer and risk profile.
• FATF Guidance for a Risk-Based Approach: Banking Sector — risk-based application of AML/CFT controls in banking.
• FATF Guidance on Beneficial Ownership of Legal Persons — current guidance supporting Recommendation 24 and the need for adequate, accurate and up-to-date beneficial ownership information.
• FATF Guidance on Beneficial Ownership and Transparency of Legal Arrangements — guidance supporting Recommendation 25 for trusts and similar legal arrangements.
• Basel Committee: Sound management of risks related to money laundering and financing of terrorism — bank governance, customer acceptance, identification, monitoring and information-sharing context.
• Wolfsberg Group: Statement on Effective Monitoring for Suspicious Activity, Part II — industry guidance on monitoring that combines customer behaviour and attributes with transaction information; used as practical industry guidance, not law.
• Wolfsberg Group: Financial Crime Principles for Correspondent Banking — includes the feedback loop between due diligence information, monitoring results and periodic relationship review in correspondent banking.

United Kingdom examples

• FCA Financial Crime Guide, FCG 3: Money laundering and terrorist financing — UK guidance on CDD and risk-sensitive ongoing monitoring, including maintaining current customer knowledge.
• FCA: Firms' customer due diligence processes and controls — findings — April 2026 supervisory findings on CDD, EDD and ongoing due diligence controls.
• FCA: Risk assessment processes and controls in firms — findings — November 2025 observations on customer and business-wide risk assessment.
• FCA: De-risking — managing money-laundering risk — current UK supervisory position that effective risk management does not require wholesale withdrawal from entire customer categories.

United States examples

• FFIEC BSA/AML Examination Manual: Customer Due Diligence — U.S. examination guidance on understanding customer relationships and risk-based, event-driven ongoing monitoring and updating of customer information.
• FFIEC BSA/AML Examination Manual — consolidated U.S. examination manual for BSA/AML controls and related topics.
• FinCEN: Bank Secrecy Act resources — official U.S. statutory and regulatory resource entry point.

Australian examples

• AUSTRAC: Overview of ongoing customer due diligence — current Australian guidance on continuous monitoring, risk review and KYC updates.
• AUSTRAC: How to monitor your customers — current guidance on monitoring customer transactions and behaviour, data coverage, investigation, escalation and assurance.
• AUSTRAC: What you must monitor for — guidance updated 31 March 2026 on unusual transactions, behaviours and record keeping.
• AUSTRAC: Ongoing customer due diligence guide — regulator guidance, updated 30 March 2026, explaining its interpretation of Australian ongoing CDD requirements.

European risk-factor guidance

• European Banking Authority: Guidelines on ML/TF risk factors — risk-factor, CDD and risk-sensitive monitoring guidance for the EU framework; use the current version and applicable successor framework for the relevant entity and date.