Africa Financial Crime Operating Models

A bank cannot build an effective African financial-crime operating model by creating one rule set called Africa. The continent contains many legal systems, regulators, financial intelligence units, currencies, payment infrastructures, customer segments and business models. Some markets have large formal banking sectors; others rely more heavily on mobile money, agents, remittance networks or cash. Some banking groups operate through locally incorporated subsidiaries, others through branches, correspondent relationships or partnerships. The practical control challenge is therefore not to find one African AML rule. It is to combine a consistent group standard with the law, supervisory expectations and reporting process that actually apply to each legal entity and activity.

The most useful mental model has five layers. First comes the global standard, principally the FATF Recommendations. Second comes the relevant regional assessment and cooperation environment, including FATF-style regional bodies such as ESAAMLG, GIABA, GABAC and MENAFATF. Third comes national law, regulation, supervisory guidance and the local financial intelligence unit. Fourth comes the bank's own legal entity, products, customers, channels and risk appetite. Fifth comes the operational control: onboarding, screening, transaction monitoring, investigation, sanctions action, suspicious reporting, quality assurance and audit evidence.

The layers matter because the same group platform can support several countries while the legal consequences remain local. A central screening engine may process names for multiple subsidiaries. A regional investigation hub may review alerts. A group data lake may calculate behavioural features. Yet the obligation to file a suspicious transaction report, the reporting deadline, the FIU receiving the report, the confidentiality restrictions, the sanctions authority and the decision maker can differ by jurisdiction. A strong model therefore centralises reusable capability without centralising away local accountability.

Africa is not one AML/CFT jurisdiction

The FATF Global Network includes nine FATF-style regional bodies. African jurisdictions participate through different regional bodies rather than one continent-wide AML supervisor. ESAAMLG covers eastern and southern Africa, GIABA covers West Africa, GABAC covers Central Africa, and several North African jurisdictions participate in MENAFATF. These bodies conduct mutual evaluations, follow-up reviews, typology work and technical-assistance activity. Their work is extremely useful to banks because it reveals how national frameworks are assessed against the FATF Standards, but a mutual-evaluation report is not itself a bank's operating law.

That distinction prevents a common mistake. A country may be assessed as having weaknesses in effectiveness or technical compliance, yet a bank still has to apply the national laws that remain in force. Conversely, a positive country rating does not remove the need to assess a particular customer's risk. Country assessment, customer assessment and transaction suspicion are different decisions.

Regional bodies also evolve. ESAAMLG, for example, publishes follow-up reports showing how member jurisdictions address technical-compliance findings over time. GIABA began its third round of mutual evaluations with Ghana in early 2026. Those developments are useful horizon-scanning inputs because they can foreshadow legislative, supervisory or industry changes. They should feed a regulatory-change process, not be converted mechanically into customer blocks.

For a bank operating across multiple African markets, the safest design is a jurisdiction obligation matrix. Each record should identify the legal entity, regulator, FIU, applicable AML/CFT/CPF framework, sanctions implementation source, suspicious-reporting channel, reporting deadline where applicable, confidentiality constraints, retention rule, escalation owner and effective date. The matrix should be versioned. Without effective dates, a bank can prove what its current policy says but not what rule applied when an old case was decided.

Global standard, local implementation

FATF provides the common architecture: risk assessment, customer due diligence, beneficial ownership, record keeping, suspicious transaction reporting, targeted financial sanctions, correspondent banking controls, wire-transfer transparency, new-technology risk and international cooperation. Banks use this architecture to design group standards because it creates a common language across jurisdictions.

The operational obligation, however, comes through local implementation. South Africa's Financial Intelligence Centre Act framework, Kenya's Proceeds of Crime and Anti-Money Laundering framework, Nigeria's national AML legislation and NFIU reporting regime, Ghana's Anti-Money Laundering Act and related Bank of Ghana/FIC guidance are examples of separate national frameworks. A learner should resist the temptation to memorise one country's terminology and use it everywhere. Even the words used for a report can vary: STR, SAR, suspicious or unusual transaction report, and related reporting types can have different meanings in different systems.

South Africa offers a clear example of local governance. Revised FIC Guidance Note 7A explains that accountable institutions must develop, document, maintain and implement a risk management and compliance programme under the FIC Act. It also places ultimate responsibility for implementation and compliance with that programme on the board or senior management, depending on the institution. That is a South African requirement and supervisory expectation; it is not a sentence to paste into every African legal-entity policy. The broader lesson is universal: the operating model needs named accountable ownership, not merely a central compliance team.

Kenya provides another example of why scope matters. The Central Bank of Kenya has issued banking-sector guidance on ML/TF risk assessment and maintains legislation and guidance relevant to banks and payment service providers. The national payments framework recognises mobile-phone money transfer operators as payment service providers under the National Payment System framework. Meanwhile, the Financial Reporting Centre operates the country's financial-intelligence reporting environment, including goAML. A group bank therefore needs to distinguish banking supervision, payment-service regulation and FIU reporting rather than treating them as one control owner.

Nigeria's NFIU describes itself as the central agency responsible for receiving suspicious and threshold-based reports, analysing information and disseminating financial intelligence to competent authorities under Nigeria's legal framework. Its public guidance shows that reporting entities use specified reporting channels, including goAML for financial institutions. The important systems lesson is not the name of the portal. It is that an external report needs controlled data mapping, authorised access, proof of submission, FIU reference capture, resubmission handling and confidentiality controls.

Ghana's Financial Intelligence Centre similarly describes itself as the national centre for receiving and analysing suspicious transaction information and disseminating actionable intelligence. The Bank of Ghana and FIC jointly published an AML/CFT&P guideline for accountable institutions in December 2022. Again, the operating model is local even when the group platform is shared.

A practical jurisdiction map

The table below is intentionally illustrative rather than exhaustive. It shows how the operating-model questions differ without pretending to replace current local legal advice.

A real institution would add every legal entity it operates and would maintain the matrix through legal and compliance governance. The table should never become an excuse for a static country checklist.

Risk-based controls without geographic stereotyping

A mature bank distinguishes country context from customer suspicion. A country, region, border area or corridor can influence inherent risk, but geography alone does not prove illicit activity. The same is true of cash, mobile money, informal-sector businesses, charities, remitters, cross-border traders and agent networks. These features can change the information a bank needs and the controls that are proportionate; they are not evidence of criminality by themselves.

The FATF risk-based approach is important here because it requires risk to be identified, understood and mitigated proportionately. It does not instruct banks to remove entire customer groups simply because analysis is harder. Poorly designed de-risking can push legitimate customers toward less transparent channels and undermine financial inclusion. A strong operating model therefore asks a more useful question: what evidence would allow the bank to distinguish expected activity from misuse for this customer, product and corridor?

For a small merchant that receives frequent low-value digital payments, the baseline may be daily retail turnover and supplier payments. For an agricultural aggregator, it may include seasonal cash-out, agent payments and rural counterparties. For a remittance company, high cross-border volume is inherent to the business, so monitoring should focus on customer and beneficiary behaviour, corridor changes, pass-through patterns, structuring, linked identities, unusual agent concentration and unexplained settlement movements rather than simply flagging every foreign payment.

The same principle applies to politically exposed persons. Political exposure requires the due-diligence and approval treatment set by applicable law and policy, but it is not proof of corruption. Adverse media is an investigative input, not a conviction. High-risk classification should drive better evidence and stronger monitoring, not prejudged outcomes.

Mobile money and agent networks

Mobile money changes the control architecture because customer interaction can be distributed among the wallet provider, telecommunications infrastructure, agents, banks, payment systems and remittance partners. The bank may not own every piece of data. That makes the operating model a problem of control ownership and data lineage as much as one of detection.

At onboarding, the provider needs identity evidence and risk information appropriate to the applicable framework and product. During use, relevant signals may include device changes, SIM or account changes where lawfully available, cash-in and cash-out behaviour, agent location, linked accounts, velocity, beneficiary novelty and rapid movement through wallets. At the agent layer, the institution may need to monitor unusual float activity, repeated override behaviour, concentration of customer activity through one agent, cash imbalances or transactions inconsistent with the agent's expected business.

These are not universal typologies that automatically prove money laundering. An agent in a transport hub may legitimately process far more cash-outs than an agent in a residential area. Seasonal agricultural or school-fee periods can create predictable peaks. Monitoring therefore needs peer groups and local context. A model trained on urban salary customers can perform badly when applied without calibration to rural wallet users.

Control ownership must also be contractual. If a bank provides settlement accounts to a mobile-money provider but does not onboard each end user, the bank should not pretend it performs the provider's customer due diligence. It should understand the relationship, the provider's regulatory status, the expected settlement flows, correspondent-like or nested exposure where relevant, and its own monitoring obligations. Where the bank and provider share responsibilities, interfaces and data-quality obligations should be explicit.

Cash economies and financial inclusion

Cash remains important in many markets for legitimate reasons. A bank should avoid a simplistic rule that large or frequent cash activity is inherently suspicious. The useful comparison is between observed behaviour and the customer's business, location, sector, historical activity and explanation.

Cash controls can combine threshold reporting where local law requires it, unusual-activity detection, branch or agent intelligence, source-of-funds checks, business-profile comparison and network analysis. Threshold reports and suspicious reports are not the same thing. A transaction can be reportable by amount without being suspicious, while a suspicious pattern can fall below any threshold. Systems should preserve this distinction so that a mandatory threshold-reporting feed is not mistaken for a transaction-monitoring conclusion.

Financial inclusion also affects control design. Simplified or tiered products can be legitimate tools where the local framework permits them. The institution should understand product limits, identity requirements, upgrade triggers, transaction caps and monitoring expectations. Weak design either creates unnecessary exclusion or allows higher-risk activity to remain inside a low-information product. Product governance should therefore test whether customer capability, product limits and control coverage still align as usage grows.

Cross-border remittances and corridor risk

Remittances are economically important and mostly legitimate. Their risk comes from the possibility that criminals use the same fast, distributed channels to move scam proceeds, mule-account funds, terrorist financing or other illicit value. The bank's job is to distinguish those patterns without turning nationality or corridor choice into a presumption of wrongdoing.

Useful evidence includes sender and beneficiary identity, relationship where available, funding source, payment purpose, frequency, amount, channel, agent, device, geography, recipient concentration, rapid onward movement and links to previously investigated parties. A pattern in which many unrelated senders pay one beneficiary who immediately cashes out may deserve review. So may a customer whose remittance behaviour changes suddenly from family support to high-frequency business-like payments through multiple recipients. But the investigation still needs context before it reaches a conclusion.

Cross-border corridor calibration matters. A transfer from Nairobi to a family member in Kampala has a different normal pattern from a corporate settlement from Lagos to London or a remittance corridor between Johannesburg and Maputo. A global threshold that ignores corridor economics will generate noise in some markets and miss risk in others.

For business analysts, the requirement should not be “monitor high-risk corridors.” It should define how corridor risk is calculated, which authoritative data feed supplies the classification, how effective dates are managed, how historical cases remain reproducible, which behavioural features are combined with corridor context and what happens when the country-risk service is unavailable.

Correspondent banking, settlement and nested exposure

African banks participate in international payment systems through correspondent relationships, regional settlement arrangements and domestic clearing infrastructures. A correspondent bank may see the respondent institution and payment-message parties but not the full underlying customer relationship. The respondent bank may have richer customer information but less visibility into the correspondent's downstream routing.

The operating model should define which institution owns which control. Correspondent due diligence covers the respondent's business, ownership, management, AML/CFT framework, customer base, products, geographies and nested relationships as required by policy and applicable standards. Payment screening evaluates parties and data in the payment. Transaction monitoring looks for behaviour across the relationship. Requests for information can close information gaps. None of these alone substitutes for the others.

Nested relationships deserve particular attention because an indirect institution may access a correspondent chain through the respondent. The risk is not that nested banking is automatically prohibited; the risk is that the correspondent may not understand who ultimately uses the relationship. Controls can include respondent disclosure, contractual expectations, payment-data analysis, RFI capability and escalation when activity materially differs from the known relationship.

Sanctions and proliferation-financing overlays

Sanctions controls also require jurisdiction discipline. United Nations Security Council targeted financial sanctions are implemented through national or regional legal mechanisms; banks then apply the law that binds the relevant legal entity. A multinational group may additionally apply US, UK or EU sanctions because of legal nexus, correspondent routing, currency, ownership, group policy or contractual requirements. Those layers should be recorded separately.

This matters operationally. A payment routed in US dollars may create an OFAC-related consideration that is not identical to the local legal rule governing the African booking entity. A European parent may operate a group policy that is stricter than local law. The system should be able to explain whether a transaction was stopped because of local law, another binding legal nexus or group risk appetite. Calling every outcome simply “sanctions blocked” destroys that evidence.

Proliferation-financing risk can also appear through trade, logistics, ownership structures and restricted goods. Banks should use the information they actually possess. A trade-finance bank may see invoices, bills of lading and goods descriptions. A retail-payment processor may see only payment parties, amount, currency and remittance text. Control design should never claim inspection of data the product does not collect.

Customer and beneficial-ownership data

Customer due diligence is only as useful as the data that can be retrieved later. A regional bank should know the customer legal entity, identifiers, beneficial owners, controllers, authorised persons, products, expected activity, business sector, relevant geographies and risk rating in a structured form where possible. Document images alone are poor monitoring inputs.

Beneficial-ownership sources vary by jurisdiction. Registry availability, verification standards and access can differ. The bank should therefore store the evidence source and verification date rather than a bare percentage. If an ownership chain changes, historical relationships should remain reconstructable because an investigator reviewing a past transaction may need to know who controlled the customer at that time.

Identity matching also needs local realism. Names may appear in different scripts or transliterations; spelling conventions can vary; people may share common names; date-of-birth or national-identifier coverage may be incomplete. Screening engines need tuning that uses additional identifiers and does not turn every fuzzy name match into an operational block. False-positive reduction should be evidence based and tested against true-match sensitivity.

Transaction monitoring and local typologies

Regional transaction-monitoring platforms are efficient when they share common infrastructure but support local calibration. A group can reuse scenario engines, data pipelines, case tooling and model governance while varying thresholds, peer groups, features and typology emphasis by product and market.

The key is to avoid two extremes. The first is country-by-country duplication, where every subsidiary builds unrelated technology and no group learning transfers. The second is global uniformity, where one threshold is applied to customers whose normal behaviour differs fundamentally. A mature bank centralises the machine and localises the understanding.

Scenario performance should be measured by alert quality, coverage, false-positive rate, case conversion, regulatory outcomes, customer impact and known gaps. If a rule produces thousands of low-value alerts from legitimate mobile-wallet usage, investigators become less able to see genuine risk. Tuning is therefore a control activity, not merely an efficiency exercise. Changes need approval, testing, effective dates and rollback capability.

Local typologies can come from FIUs, supervisors, law enforcement, national risk assessments, FATF/FSRB publications and the bank's own investigations. They should enter a controlled typology lifecycle: source, assessment, control impact, implementation decision, test evidence and review date. A news headline should not become a production rule without validation.

Alert, case, investigation and reporting

An alert is a signal. A case brings signals together around a customer, account, payment or network. An investigation evaluates evidence and forms a reasoned conclusion. External reporting is a legal or regulatory action under the applicable local framework. Keeping those stages separate is essential in a regional model.

The first step is data validation. Investigators should know why the alert fired, whether the input data were complete, whether exchange rates or country codes were mapped correctly and whether linked transactions were missed. They then compare activity with the customer profile, related parties, prior cases, counterparties and external information. Customer contact may be appropriate in some AML investigations, but the workflow must respect tipping-off and confidentiality restrictions.

The decision to file belongs to the authorised function under local law and policy. A regional analyst can prepare the case, but the accountable legal entity should remain clear. One group case can therefore produce several local decisions. For example, a customer may hold accounts with two group subsidiaries, and each entity may need to assess whether it has its own reporting obligation. The case system should store decisions by entity rather than one global SAR_FILED flag.

External reports should be protected from unnecessary access. The platform needs role-based permissions, versioned narrative, submission time, recipient FIU, acknowledgement or reference, attachments, follow-up requests and any permitted internal intelligence sharing. Cross-border sharing of report content or FIU-originated information requires legal and confidentiality analysis; a group policy cannot assume everything can be copied into a global data lake.

Egmont Group principles are relevant because FIUs rely on secure, trusted exchange and operational independence. That reinforces the need for banks to protect information received through FIU channels and to distinguish bank-generated investigation material from intelligence supplied under restricted conditions.

Regional hub versus local accountability

A regional hub can bring scale, specialist skills and consistency. It can conduct first-level alert review, screening investigation, quality assurance, scenario analytics, list-management support, training, MI production and technology support. Those capabilities are valuable when individual subsidiaries are small.

But the hub must have a clear responsibility matrix. Local legal interpretation, FIU reporting authority, regulator engagement, sanctions disposition and customer-exit approval may remain with local officers. The exact split differs by institution and law. What matters is that the workflow does not confuse who performs analysis with who owns the legal decision.

Service-level agreements should reflect risk rather than only productivity. A hub can meet an average alert SLA while still missing local reporting deadlines. MI should therefore show ageing by legal entity, scenario, severity and deadline. Quality assurance should sample local-specific decisions, not only generic case-writing quality.

Resilience matters too. If a central screening service fails, subsidiaries need pre-agreed contingency procedures. If a regional case platform is unavailable, time-sensitive sanctions or reporting actions cannot simply wait. Business continuity design should identify which decisions require local fallback, how evidence is preserved and how manual actions are reconciled when systems recover.

Data architecture for a multi-jurisdiction bank

The most important data attribute in this chapter is often not customer nationality. It is applicable jurisdiction and legal entity. A customer can have one nationality, live in another country, hold an account in a third, pay a beneficiary in a fourth and use a correspondent in a fifth. Each dimension has a different control meaning.

A useful event model stores at least the booking entity, customer entity, product, account, channel, transaction location where relevant, sending and receiving jurisdictions, payment agents, currency, sanctions-screening scope, case ownership and applicable rule version. The obligation engine can then determine which local procedure, approval path or external reporting destination applies.

Data lineage should show source system, extraction time, transformation, enrichment and consumption. This becomes critical when the same mobile-money or payment feed is transformed differently for fraud, AML and regulatory reporting. If a country code is lost during mapping, sanctions and transaction monitoring can fail simultaneously while dashboards still show green system status.

Privacy and localisation requirements should be captured as design constraints, not discovered after deployment. A regional model may need data minimisation, pseudonymisation, local storage, restricted fields or federated analytics depending on applicable law and bank interpretation. The correct solution is not to assume cross-border sharing is always prohibited or always allowed. It is to record the lawful basis and approved sharing pattern for the data in question.

Business analysis, architecture and testing

A strong business analyst turns jurisdiction knowledge into testable requirements. “Comply with local AML law” is not a useful requirement. A better requirement states which event triggers the workflow, how legal entity is resolved, what data are mandatory, which policy version applies, who can approve the decision, what happens if data are missing, how the external report is generated, which evidence is retained and what MI proves the control operated.

Acceptance criteria should include positive, negative and boundary scenarios. Positive tests prove that known high-risk patterns reach the correct local queue. Negative tests prove that ordinary salary, merchant, remittance and wallet behaviour can clear without unnecessary friction. Boundary tests cover threshold edges, effective-date changes, currency conversion, daylight-saving or timezone differences, duplicated events, missing identifiers and entity changes.

Jurisdiction tests are especially important. A South African case must not be routed to a Kenyan FIU workflow because the customer happens to be Kenyan. A payment involving Ghana should not automatically invoke Ghanaian reporting if the booking entity and local facts do not create that obligation. A Nigerian reporting schema change should not alter the narrative template used by other legal entities. These are architecture tests, not merely compliance reviews.

Screening tests should include aliases, transliterations, common names, missing dates of birth and ownership relationships. Monitoring tests should include local peer groups, mobile-wallet velocity, agent behaviour, cross-border remittances, corporate settlements and legitimate seasonal peaks. Case tests should verify confidentiality, segregation of FIU-report content, audit history and maker-checker controls.

Failure-mode testing is equally important. Test unavailable country-risk feeds, late mobile-money data, broken agent identifiers, inaccessible FIU portals, stale sanctions lists, duplicate payment events and a regional case-platform outage. The bank should know in advance which controls fail closed, which enter a degraded mode and which require local manual action.

Mini case: a remittance pattern across three markets

Consider a composite example. A regional banking group has a Kenyan subsidiary, a South African subsidiary and a Ghanaian correspondent relationship. A Kenyan retail customer normally receives salary and sends two small monthly family-support payments. Over three weeks, the customer begins receiving credits from many unrelated domestic senders and sending frequent transfers to several beneficiaries through a remittance partner. Some beneficiaries cash out rapidly through agents in another country. The amounts are individually modest and below any simple high-value threshold.

The monitoring system should not label the pattern suspicious because it involves Africa-to-Africa remittances or agents. It should identify the behavioural change: many new inbound parties, rapid pass-through, new beneficiaries, higher velocity and a changed purpose profile. The alert should route to the Kenyan legal entity because that entity owns the account and customer relationship.

The investigator validates the data, reviews the customer profile, examines linked accounts, checks whether the incoming senders share devices or other identifiers where lawfully available, reviews the remittance beneficiary network and checks prior alerts. The investigator also determines what information comes from the remittance partner and what the bank can independently verify.

Suppose the pattern is consistent with a suspected mule network associated with scam proceeds. The authorised Kenyan process decides whether the facts meet the local suspicious-reporting threshold and handles reporting to the Kenyan FRC. A related South African account identified through the network is referred to the South African entity for its own assessment; the group does not assume that the Kenyan report satisfies any South African obligation. The Ghanaian correspondent relationship is reviewed only to the extent that the bank's evidence indicates relevant activity; it is not treated as suspicious merely because funds passed through a Ghanaian institution.

If the bank restricts the Kenyan customer's account, that action is recorded separately from the external reporting decision. Customer communication follows approved language that does not reveal confidential reporting. If the investigation shows that the customer's profile was stale, KYC remediation is another separate outcome. One event can therefore produce multiple controlled decisions: AML reporting, customer-risk change, account restriction, linked-entity referral and monitoring-tuning feedback.

For technology teams, the case demonstrates why a single financialCrimeStatus field is inadequate. The data model needs separate states for alert, case, reporting, sanctions, customer risk, payment disposition and relationship action, each with its own owner, evidence and timestamp.

What commonly fails

The first failure is treating Africa as a single risk score. That hides legal differences and encourages geographic stereotyping. The second is centralising investigation without defining local decision rights. The third is using one transaction-monitoring threshold across customer populations that behave differently. The fourth is assuming mobile-money data have the same fields and quality as core-bank payment data. The fifth is copying FIU or suspicious-report content across borders without approved confidentiality controls.

Another failure is measuring only throughput. A regional hub can close many alerts quickly while missing the cases that matter. Better MI combines ageing, severity, reporting deadlines, true-case yield, repeat alerts, data defects, QA findings, customer impact, rule performance and remediation status. Metrics should be visible by legal entity so a strong regional average does not hide a weak subsidiary.

Finally, regulatory change can fail quietly. A new law or FIU schema may be documented by compliance but not reach technology, training or procedures. The fix is end-to-end traceability: source publication, legal interpretation, policy change, requirement, code/configuration change, test, deployment, training and post-implementation assurance.

The principle to keep

The strongest African financial-crime operating model is neither a collection of isolated country teams nor one global workflow imposed everywhere. It is a federated model: common standards, common technology and shared expertise where they genuinely help, combined with local legal interpretation, local FIU/reporting accountability and controls calibrated to the actual products and customers in each market.

That model is harder to design than a country blacklist or a generic regional policy, but it is much more defensible. It supports financial inclusion, makes better use of data, preserves local accountability and gives the bank an audit trail that can explain not only what decision was made, but why that decision was correct for that legal entity, customer, channel and point in time.

Operational deep dive: mobile money, agents and distributed controls

Mobile money changes the financial-crime operating model because the service can be delivered through several parties. A customer may register with a wallet provider, deposit or withdraw cash through an agent, fund transfers through a settlement bank, use a domestic or cross-border payment rail and pay a beneficiary served by another provider. Each participant can see different data and may own different controls.

The first design task is therefore to map the service chain and assign control ownership. The bank should know who performs end-user CDD, who onboards and supervises agents, who monitors wallet behaviour, who screens parties, who monitors the settlement account, who investigates suspicious activity and which legal entity decides whether to report to the local FIU. A regulated partner is useful evidence of governance, but it does not remove the bank's responsibility for the risk created by its own relationship and services.

Agent networks

Agents extend financial access but create a distributed control surface. Useful agent-risk information can include location, expected transaction mix, float behaviour, cash-in/cash-out balance, customer concentration, transaction velocity, unusual overrides, linked accounts and previous investigations. Peer comparison matters: a transport-hub agent can legitimately behave very differently from a neighbourhood shop.

Signals are not conclusions. A sudden increase in cash-outs may indicate misuse, but it may also follow the closure of a nearby agent, a seasonal payment cycle or a legitimate commercial event. Investigators should validate the agent identifier, understand the operational context and then examine customer and transaction links.

Wallet behaviour needs local calibration

Traditional bank scenarios often perform badly when copied directly into wallet environments. Wallet transactions may be lower value, higher frequency and closely connected to agent activity. Relevant features can include rapid cash-in followed by transfer or cash-out, many unrelated senders to one wallet, one device associated with many accounts where lawfully available, newly opened accounts operating immediately at high velocity, repeated beneficiary changes and sudden cross-border activity.

Every feature needs an innocent comparator. Many senders can indicate a mule account, but also a merchant or community collection. Rapid cash-out can indicate pass-through, but also legitimate family support. Device sharing may be suspicious in one context and normal where an agent or household shares equipment. Good monitoring therefore combines behaviour, customer profile, product, peer group and local knowledge.

Tiered products and financial inclusion

Where local frameworks permit simplified or tiered products, the limits form part of the control design. Balance caps, daily or monthly transaction limits, cross-border restrictions and product functionality should be enforced consistently. The institution should define when a customer's usage requires an upgrade to a higher-information tier and how multiple linked low-tier accounts are detected.

The control objective is not to make low-income or cash-reliant customers harder to bank. It is to apply proportionate controls that preserve access while still identifying misuse. Blanket de-risking can reduce transparency by pushing legitimate activity outside regulated channels.

Settlement and reconciliation as financial-crime evidence

Wallet ecosystems rely on settlement accounts, agent float and ledger balances. Reconciliation between wallet liabilities, settlement funding and payment-system positions can reveal data defects, fraud or unexplained activity. Financial-crime teams should therefore understand the same data lineage used by payments and finance teams.

A missing agent identifier or duplicated wallet event may not create an accounting imbalance, yet it can materially weaken AML monitoring. Data-quality controls should measure not only whether transactions arrived, but whether the fields needed for the control arrived correctly.

Partner reliance and RFI capability

A settlement bank may not hold end-user KYC for the payment provider's customers. Its own control framework should reflect what it genuinely sees: provider due diligence, settlement behaviour, payment-message data, contractual information rights and requests for information. If the provider repeatedly cannot explain unusual flows or provide expected evidence, that can become a relationship-risk issue.

The bank should avoid claiming controls it does not operate. “All wallet customers are screened by the bank” is inaccurate if screening is actually performed by the provider. The correct operating model states who screens, what standards apply, what assurance the bank obtains and what happens if the provider's control fails.

Worked example: activity concentrated through one agent

A wallet provider identifies one agent whose cash-out volume has increased sharply over six weeks. Many withdrawals are funded by newly active wallets that receive transfers from unrelated people and move most value onward within minutes.

Analysts first test operational explanations: agent-network changes, seasonal payments, system-routing changes and data quality. When those do not explain the pattern, they examine linked wallets, identities, devices where permitted, beneficiary networks, fraud complaints and prior cases. Several incoming transfers are linked to confirmed scams and the wallets appear to be mule accounts.

The response is not one status. Customer cases may be escalated for suspicious-reporting assessment. Fraud teams may pursue recovery and victim-related actions. The provider may restrict the agent under contract. Monitoring teams may refine network detection. If a bank provides the provider's settlement account, that bank separately considers whether its own evidence creates an AML concern about the corporate relationship.

The lesson is simple: mobile money is not inherently high risk. Weak ownership, weak data and poorly calibrated controls create risk. A mature model knows which participant sees which evidence and makes each decision at the correct legal and operational level.

Advanced practice: federated regional governance and jurisdiction routing

Regionalisation can improve financial-crime control by sharing investigators, screening expertise, analytics, data engineering, quality assurance and technology. The risk appears when operational centralisation is mistaken for legal centralisation. A case can be analysed in one country while the accountable institution, regulator, FIU and customer relationship sit in another.

The safest design is federated: group functions define minimum standards and common capabilities; regional hubs provide scale; local legal entities retain the decision rights that law, regulation and approved governance place on them.

Build a jurisdiction obligation matrix

A regional platform should resolve obligations from structured data rather than a country name in free text. Useful attributes include booking legal entity, regulator, FIU, product and licence, customer domicile, transaction origin and destination, currency, correspondent route, effective rule version, data-sharing restrictions and decision owner.

These fields have different meanings. A Kenyan national resident in South Africa may hold an account booked by a South African entity and pay a Ghanaian beneficiary. Nationality, residence, booking entity and beneficiary country all matter, but they do not all decide the same obligation. The system should use the dimension relevant to the decision being made.

Separate law, legal nexus and group policy

A multinational bank may apply controls stricter than the local minimum. The evidence should distinguish:

1. the local legal obligation of the booking entity;
2. another binding legal nexus, such as a sanctions regime relevant to routing or entity exposure; and
3. a group-policy restriction based on risk appetite.

This distinction matters when explaining customer or payment outcomes. A transaction declined under group policy should not later be described as legally prohibited unless legal analysis supports that statement.

Central investigation, local entity decision

A useful case model has one group case plus one or more entity decisions. Common facts, network links and analysis can sit in the group case. Each entity record stores the local legal assessment, authorised approver, FIU/reporting decision, submission reference and customer or payment action.

This avoids both duplication and loss of accountability. A network spanning Kenya and South Africa can be analysed once by a regional team while each subsidiary still records its own decision. One global SAR_FILED flag is inadequate because it cannot prove which entity reported what and when.

Protect FIU-originated information

Bank-generated case material and FIU-originated information may have different confidentiality constraints. Egmont Group material emphasises secure information exchange, confidentiality and FIU operational independence. Systems should therefore record information provenance and apply access controls accordingly.

If a local FIU requests additional information, the workflow should preserve the request, due date, authorised recipient, response and submission evidence. Regional access should follow the approved sharing model rather than automatically copying the request into every group repository.

Common engine, local calibration

Transaction-monitoring and screening infrastructure can be shared while calibration reflects the actual business. Segmentation may consider product, customer type, channel, corridor, agent type and risk. A threshold suitable for a salary account may be useless for a merchant settlement account. High cash activity may be ordinary for an agent but unusual for a dormant retail customer.

Scenario changes should be governed like other production changes: purpose, data inputs, calibration population, test results, approval, effective date and rollback. Local tuning should remain visible to the regional team so that consistency does not depend on undocumented exceptions.

Regulatory change must be traceable

The delivery chain should be visible from source to control:

official publication → legal interpretation → policy impact → requirement → configuration/code → test → deployment → training → assurance.

Effective dates are critical. An investigator reviewing an old event should see the rule that applied on that date, not the current rule. Versioning is therefore a financial-crime requirement as well as a technology discipline.

Architecture and failure modes

A scalable regional platform normally combines customer data, transaction/channel data, reference and obligation services, screening/monitoring, case management, external reporting and assurance. Each capability needs defined failure behaviour.

If a country-risk feed fails, the system should not silently substitute a default. If a sanctions-list update fails, the bank should enter its approved contingency mode. If the FIU portal is unavailable close to a local deadline, the responsible entity should know the approved fallback and retain evidence of attempts. If the central case tool is unavailable, time-sensitive local decisions still need a controlled path.

Essential regression tests

A practical test suite should vary jurisdiction dimensions independently. Test the same nationality under different booking entities; the same entity with different beneficiary countries; events before and after a rule effective date; missing legal-entity or agent identifiers; common-name and transliteration screening cases; regional access to restricted FIU content; local monitoring threshold changes; and outages of list feeds, case tools and reporting portals.

The most valuable negative test is one that proves legitimate high-volume behaviour can clear. Without negative testing, a control can appear effective simply because it blocks or alerts too much.

Governance and MI

Regional governance should show entity-level ageing, high-risk populations, overdue reviews, cases approaching local deadlines, unresolved screening matches, failed data feeds, scenario performance, QA findings, regulatory-change items and remediation status. A regional average can hide a small subsidiary with repeated control failures, so legal-entity drill-down is essential.

The operating principle is straightforward: analyse centrally where it improves quality, decide locally where accountability requires it, and make the boundary visible in data and governance.

Practice close: acceptance criteria and test prompts

A sound multi-jurisdiction design should prove that every customer, alert and case is linked to the correct booking legal entity; nationality, residence and transaction geography remain separate concepts; the rule version applicable on the decision date is retained; local reporting ownership is explicit; FIU-report content is restricted; and customer, payment, sanctions, fraud and reporting outcomes are recorded separately.

Test the model with cases that expose routing errors. Use the same nationality under different booking entities. Change beneficiary country without changing the booking entity. Process identical events before and after a rule effective date. Remove an agent ID or legal-entity code and confirm a visible data-quality exception. Test a legitimate high-volume merchant against a rapid pass-through mule pattern. Verify common-name and transliteration screening cases. Simulate an FIU portal outage and a failed country-risk or sanctions-list feed.

A reviewer should be able to answer: which entity owns the customer; which regulator and FIU apply; which controls are performed locally, regionally or by a partner; what wallet, agent and remittance data the bank genuinely receives; what the bank does when critical data are missing; and whether the original rule, list and customer profile can be reconstructed later.

Reject four shortcuts. Africa is not one risk score. Mobile money and cash are not suspicious by definition. A regional investigator does not automatically own the legal reporting decision. A regulated partner does not eliminate the bank's risk in its own relationship.

The final test is whether the operating model can explain one case in plain language from source event to local legal decision, with enough evidence to show why that outcome was appropriate for that legal entity at that point in time.

Masterclass: one network, several entity decisions

Consider a composite case spanning a banking group's Kenyan and South African retail entities and a payment provider for which the group supplies settlement services. Network analytics identify accounts receiving many low-value credits from unrelated people and forwarding most funds quickly to a small group of beneficiaries. Some value is cashed out through mobile-money agents. Several source payments are later linked to reported scams.

The regional investigation team first validates the network. Duplicate transactions are removed, beneficiary identifiers are checked and an apparent shared-device link is shown to be an agent terminal rather than proof that customers are controlled by the same person. One high-volume account is a legitimate merchant and is excluded after its activity is reconciled to the business profile.

The remaining accounts show stronger mule indicators: dormant accounts becoming suddenly active, many unrelated senders, rapid pass-through, shared beneficiaries and links to confirmed fraud proceeds. Fraud intelligence strengthens the AML analysis, but fraud and AML remain separate decisions. Fraud teams may focus on recovery and victim outcomes; AML teams assess suspicion and external reporting.

The group case then branches by legal entity. The Kenyan accounts are assessed under the Kenyan entity's approved process and, where the local reporting threshold is met, reported to the Kenyan Financial Reporting Centre. The South African accounts are assessed separately under the South African entity's FIC Act framework. The bank does not assume that a report by one subsidiary satisfies the other subsidiary's obligation.

The payment provider is also reviewed, but not presumed complicit. Investigators assess whether settlement flows match the known relationship, whether the provider can explain the affected wallet and agent activity, and whether its responses show effective controls. If the provider repeatedly cannot supply expected evidence, that may become a separate relationship-risk issue.

The case platform records bank-generated network evidence centrally where permitted, while external-report content and FIU information remain access restricted. Customer restriction, fraud action, AML reporting, risk-rating change and relationship exit are stored as different outcomes with different owners and timestamps.

Finally, the case feeds back into control design. Analytics add a network feature for shared beneficiaries and rapid onward movement, but back-test it against legitimate merchants and savings groups. Technology fixes an agent-ID lineage gap. Provider-management teams strengthen high-risk RFI expectations.

The case demonstrates the core model: share analysis where it improves understanding, preserve local legal accountability, and never let a regional case status erase the different decisions made by each entity.

From a regional policy to a working corridor-control model

A regional financial-crime policy becomes useful when a bank can explain how it applies to a particular service, local entity and customer journey. A broad statement that a corridor is “high risk” does not tell an operations team which information to collect, who should investigate a concern, which institution owns a reporting decision or what happens when an agent loses connectivity. Those questions require an operating model that is specific enough to test without pretending that every African market has the same rules.

The following corridor launch is fictional. Its workflow, evidence model and management measures are proposed bank controls, not statutory requirements or a description of one existing payment scheme. A group bank provides a remittance service through two locally regulated entities and a network of contracted payout agents. The country teams retain responsibility for confirming the applicable laws, permissions, reporting routes, sanctions obligations and data-sharing constraints before the service is used.

Kenya's central bank, for example, publishes guidance on how banking institutions should assess money-laundering and terrorism-financing exposure. That is a jurisdiction-specific supervisory source, not an Africa-wide operating rule. The design discipline is to identify the relevant local source for each entity and then document how its requirements affect the service. Primary source: Central Bank of Kenya's risk-assessment guidance announcement.

Start with the service map and the money map

The service map identifies who offers the product, accepts the instruction, holds the customer relationship, processes the payment and provides the payout. The money map identifies which accounts or balances move, which institutions provide settlement and how the customer receives value. The maps may overlap, but they answer different questions. A technology provider can move data without becoming the institution responsible for every legal decision; a settlement institution may see an aggregate position rather than the original customer instruction.

For the fictional launch, the product team records the local contracting entity, the sender-facing channel, each processing intermediary, the payout arrangement and the permitted customer types. It also records whether the bank sees the underlying customer directly or receives information from a partner. This reveals where evidence is available and where the bank depends on another institution's controls or information response.

The control team should challenge gaps between the two maps. Can a payout occur before the bank receives the information its local procedure needs? Can an agent change the intended recipient after the bank's review? Does a pooled settlement account obscure which individual transfers created the balance? These are questions for product and legal design, not assumptions that should be resolved by inventing a universal message or settlement sequence.

Give every control decision an accountable entity

A regional team may provide expertise and shared monitoring, but the decision record should identify the legal entity responsible for the relevant obligation. It should distinguish a regional analyst's recommendation from a locally authorised decision. The same customer activity can be relevant to more than one entity without making one entity's report a substitute for another's independent assessment.

The proposed case model therefore links a regional view of related activity to separate local decision records. Each local record contains the applicable basis, evidence available to that entity, authorised reviewer, outcome and required follow-up. Where information cannot lawfully be shared in full, the design should document a permitted alternative rather than hiding the limitation or exporting the complete file regardless.

A shared case identifier is useful for coordination, but it should not expose confidential reporting decisions to every employee who can see the customer's payment history. Access should follow purpose and authority. A frontline employee may need to know that further customer information is required without being given the narrative of a confidential report or the details of another jurisdiction's investigation.

Design agent evidence before expanding the network

An agent relationship creates more than a new distribution point. It creates a place where information can be collected, misunderstood, altered or lost. The bank's assessment should examine the actual service performed, staff competence, identity checks, record capture, device access, connectivity, incentives, complaints and the ability to respond to a subsequent enquiry.

In the fictional service, the bank uses a controlled agent record with a stable identifier, authorised locations, approved services, current status and the relevant contract version. A transaction is connected to the agent that performed the activity, not merely to the network's head office. When an agent is suspended, the system should stop the affected activity under the approved operating rule without deleting the historical record needed to review earlier transactions.

Monitoring should distinguish agent behaviour from customer behaviour. An agent with an unusual concentration of repeated recipients may justify review of its practices, but that observation does not establish that every customer using the location is suspicious. A customer with ordinary activity should not inherit an unexplained adverse classification solely because an internal agent review is open. The bank needs a reasoned connection between the observed pattern and the action it takes.

These are illustrative internal controls. The permitted evidence types, retention rules and agent obligations must be determined locally.

Plan for unreliable connectivity without accepting invisible work

A connection failure can create uncertainty about both the customer outcome and the control outcome. An agent may not know whether a request reached the bank. The bank may not know whether a payout was completed. A customer may retry through another location. Treating each retry as an unrelated instruction can create duplication; treating every unanswered request as successful can conceal unpaid customers or unresolved controls.

The service should have a documented method for correlating attempts, determining the authoritative state and resolving uncertainty. That method must fit the actual product and partner arrangement. It should specify whether any offline activity is permitted, what limits or controls apply, and which transactions must wait for restored connectivity. The presence of a mobile-money or agent channel does not itself justify offline approval.

After recovery, the bank should reconcile the instructions, agent events, customer outcomes and financial records. Items should be identified individually as completed, reversed, rejected, still uncertain or requiring another defined action. A difference in aggregate value is useful evidence of a problem, but matching totals alone do not prove that the correct recipients were paid. Two equal-value errors can offset each other while both customers remain affected.

A contingency should also address the customer conversation. Staff should be able to explain an operational delay and provide a traceable reference without disclosing confidential control decisions. The bank should not promise that a payment is completed merely because a sender's account was debited or an intermediary acknowledged receipt. Customer communication should follow the evidence available at the relevant stage.

Review risk without turning geography into a verdict

A corridor assessment should consider the service and the way it is used. Relevant questions in the fictional example include who the customers are, the purpose of transfers, partner and agent controls, information quality, cash involvement, transaction behaviour, settlement arrangements and the bank's ability to investigate concerns. A country label cannot answer those questions by itself.

The same care applies to individual customers. Irregular income, cash use or limited conventional documentation may require a suitable assessment, but none of those facts alone explains whether funds are criminal. The bank should examine available evidence and the options permitted by local rules. Where an alternative verification approach is lawful and appropriate, the design should support it with an auditable decision rather than forcing staff to enter inaccurate information into a rigid form.

A customer may also have a legitimate explanation for a new pattern. Seasonal agricultural income, school expenses or family support can change the timing and value of remittances. These explanations should be evaluated rather than automatically accepted or rejected. A strong review records what was claimed, what corroborated it, what remained unexplained and why the resulting action was proportionate.

The purpose of this design is not to weaken controls. It is to make them evidence-based and explainable. Unnecessary exclusion can damage legitimate customers while providing little insight into actual abuse. Conversely, an inclusive product still needs a response when the bank cannot meet a required control or when the evidence supports suspicion. The operational model should make both decisions possible without relying on stereotypes.

Test reporting and investigation as separate outcomes

The fictional group tests several related events: an unusual transfer requiring review, a completed investigation with no local reporting obligation identified, a case requiring a local suspicious report, and a payment subject to a separate sanctions decision. The expected outcome for each case is approved by the appropriate local control owner. One generic flag called “financial crime positive” would be inadequate.

Where reporting is required, the test should demonstrate correct routing, data, authority and the local submission process. It should also show how failures, corrections and acknowledgements are handled. A report generated by the regional platform but never accepted through the intended local channel is not the same operational result as a completed submission. The bank must be able to identify the difference and assign the remaining action.

The investigation record should remain understandable even when no external report is filed. It should connect the original concern, relevant customer and transaction context, evidence considered, decision and follow-up. A non-reporting outcome is not a licence to delete the case or remove the facts that justified the review. Equally, an external report should not automatically close customer-risk, agent-remediation or payment-reconciliation work.

Use launch measures that reveal unresolved control risk

The first weeks of the fictional launch are monitored through a small number of connected measures. The bank examines unresolved payout states, missing evidence by agent, unanswered information requests, cases awaiting local decisions, reporting acknowledgements and repeated defects by source. It also examines customer complaints and avoidable repeat requests caused by its own systems.

Each measure should have an owner and an explanation of what action a deterioration would trigger. An increase in alerts may reflect better detection, weaker data or a changed customer population; the count alone cannot establish which. A low rejection rate may reflect good processing or a failure to apply controls. The bank needs to investigate the reason rather than reward a superficial number.

Before expanding the service, the accountable teams should review representative completed and failed journeys, not only the happy path. They should be able to reconstruct the customer instruction, agent activity, local decision, financial outcome and any subsequent correction. Outstanding limitations should be recorded with a responsible owner and a clear restriction on the scope of the launch where necessary.

The resulting operating model is regional in its reusable capabilities but local in its legal decisions. That is the practical balance: share tools, improve evidence and coordinate investigations, while retaining the country-specific authority and reasoning that make each action defensible.

References and further reading

These sources were used to review the chapter. They are public primary or official-sector sources. Country-specific requirements should always be checked against the current law, regulator/FIU guidance and the bank's approved legal interpretation before operational use.

Global standards and regional assessment

• Financial Action Task Force, FATF Recommendations: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
• Financial Action Task Force, Guidance for a Risk-Based Approach: The Banking Sector: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-banking-sector.html
• Financial Action Task Force, FATF Global Network and FATF-style regional bodies: https://www.fatf-gafi.org/en/countries/global-network.html
• Eastern and Southern Africa Anti-Money Laundering Group, About ESAAMLG: https://www.esaamlg.org/index.php/about_esaamlg_history
• Eastern and Southern Africa Anti-Money Laundering Group, Mutual evaluations and follow-up reports: https://www.esaamlg.org/index.php/Mutual_Evaluations_Second
• Inter-Governmental Action Group against Money Laundering in West Africa, GIABA member states and programme areas: https://www.giaba.org/member-states/index.html
• Action Group against Money Laundering in Central Africa, GABAC: https://gabac.org/
• Egmont Group of Financial Intelligence Units, Core documents and FIU cooperation: https://egmontgroup.org/
• Egmont Group, Information Exchange Working Group: https://egmontgroup.org/working-groups/iewg/

South Africa

• Financial Intelligence Centre, Revised Guidance Note 7A on implementation of the FIC Act: https://www.fic.gov.za/wp-content/uploads/2025/09/Revised-Guidance-Note-7A-%E2%80%93-Implementation-of-various-aspects-of-the-FIC-Act.pdf
• Financial Intelligence Centre, goAML registration and regulatory reporting portal: https://goweb.fic.gov.za/goAMLWeb_PRD/Home
• Financial Intelligence Centre, Targeted Financial Sanctions portal: https://tfs.fic.gov.za/

Kenya

• Central Bank of Kenya, Legislation and Guidelines: https://www.centralbank.go.ke/policy-procedures/legislation-and-guidelines/
• Central Bank of Kenya, Guidance Note on Conducting Money Laundering / Terrorism Financing Risk Assessment: https://www.centralbank.go.ke/2018/03/29/guidance-note-conducting-money-laundering-terrorism-financing-risk-assessment/
• Central Bank of Kenya, National Payments System and mobile phone money transfer services: https://www.centralbank.go.ke/national-payments-system/
• Financial Reporting Centre, Kenya, goAML portal and reporting-institution information: https://goaml.frc.go.ke/goAML_Prod/Home
• Financial Reporting Centre, Kenya, Guidance to Reporting Institutions on Suspicious Transaction and Activity Reporting: https://www.frc.go.ke/wp-content/uploads/2025/09/Guidance-to-Reporting-Institutions-on-Suspicious-Transaction-and-Activity-Reporting.pdf

Nigeria

• Nigerian Financial Intelligence Unit, About the NFIU and its statutory mandate: https://www.nfiu.gov.ng/AboutUs
• Nigerian Financial Intelligence Unit, Frequently Asked Questions on Suspicious Transaction Reports for Reporting Entities: https://www.nfiu.gov.ng/Faqs

Ghana

• Financial Intelligence Centre, Ghana, About the FIC and its mandate: https://fic.gov.gh/about-us.html
• Financial Intelligence Centre, Ghana, public resource portal: https://fic.gov.gh/
• Bank of Ghana and Financial Intelligence Centre, AML/CFT&P Guideline for Accountable Institutions, December 2022: https://www.bog.gov.gh/wp-content/uploads/2022/12/AML-CFT-P-GUIDELINE-23-12-2022.pdf

International banking control design

• Basel Committee on Banking Supervision, Sound management of risks related to money laundering and financing of terrorism: https://www.bis.org/bcbs/publ/d505.htm
• Wolfsberg Group, Standards and guidance: https://wolfsberg-group.org/resources