It is 08:14 on a Thursday at a Lagos Tier 1 bank. The payment-systems lead is reading the ngCERT advisory that landed yesterday. He spent the morning running a quiet inventory of his own card-management subnet — who has admin access, which service accounts can modify card rules, when the last audit happened. The answers do not let him close the printout and move to the next item in his queue.
The advisory's recommendations are correct. They are also a control list, which is what regulatory advisories must be, and they describe what to do without naming where each control has to land. The companion DSI briefing covers the threat-actor lineage. This piece is the engineering side — the four primitives that close the gap between implement real-time fraud detection on the advisory and the system that would have caught 3,421 coordinated withdrawals across three cities in one night on the production cluster.
Key takeaways
- The rules that decide whether an ATM dispenses cash live on the issuer switch and the card-management platform. FASTCash compromises target this layer, not the ATM. Defending the ATM is defending the wrong floor of the building.
- Four primitives carry the defence — HSM-backed card keys, two-tier velocity controls with an out-of-band veto, cross-country anomaly correlation, and network segmentation of the card-management subnet.
- An attacker who compromises the issuer switch should not be able to extract the card-signing keys. The HSM enforces that separation in hardware. Software-side key storage is the issuer switch trusting itself.
- A control that runs on the same compute substrate as the attacker is a control the attacker can suppress. The out-of-band velocity tier sits on separate infrastructure with separate credentials and the authority to override the switch.
- Per-account fraud detection misses the FASTCash signature. Each individual withdrawal looks legitimate. The signature is the simultaneity across accounts, geographies, and subsidiaries — and that only shows up to a detector watching the network, not the account.
Where the Rules Actually Live
When a card is dipped at an ATM, the ATM does not decide whether to dispense cash. It sends an ISO 8583 authorisation request to the acquirer, which routes it to the card issuer's switch. The switch holds the rules — daily withdrawal limit, card status, available balance, country restrictions, fraud holds. It evaluates the request, returns approved or declined, and the ATM either dispenses or doesn't.
FASTCash compromises target the switch and the card-management platform that feeds it. Once an attacker holds administrative access to either, they can modify the rules for chosen card ranges — raise the limits, disable the velocity gates, suppress the fraud flags. From the ATM's point of view, every authorisation response is correctly formatted and legitimately signed. The ATM is not broken. The switch is doing exactly what its current rules say to do. The current rules are the attack.
The path to that access is well-documented in the FASTCash literature and matches what ngCERT describes. Phishing into the corporate IT environment. Lateral movement across shared file shares and reused credentials. Privilege escalation. Months of dwell time watching the rhythm of legitimate administration. Then the modifications, in a cadence that mimics normal activity, and the coordinated cash-out night that follows.
The HSM Is the Wall the Switch Is Not
The load-bearing primitive is the Hardware Security Module that holds the cryptographic keys signing every authorisation response. A well-engineered bank stores those keys in a physical HSM, FIPS 140-3 Level 3 or 4, in a tamper-protected enclosure. The HSM exposes a narrow interface that lets the switch request signatures but never lets the switch extract the key material itself.
This matters because the attackers in the UBA operation held administrative access to the switch. Administrative access to the switch should not equal access to the keys the switch uses to sign responses. The HSM enforces the separation in hardware. The blast radius of a switch compromise is bounded by what the attacker can ask the HSM to sign before detection.
The failures we see in mid-market African banks usually fall into three patterns. HSM-bypass — a software-side key store was added for "performance reasons" and became the production path. Shared credentials — HSM admin credentials are shared with the broader payment-systems team, so reaching the broader team's credentials lets the attacker re-key rather than extract. Operational drift — firmware years out of date, key rotation silently abandoned, audit logging turned off because nobody understands how to read it. Each degrades the load-bearing primitive into a checkbox primitive.
Two Velocity Gates, One Out of Band
The control that would have caught 3,421 withdrawals across three cities is a velocity gate watching the authorisation rate against any defined card population. A sensible threshold — say, ten times the historical maximum hourly cash-out rate — would have fired within thirty minutes.
The reason the gate did not fire, assuming the bank had one, is that it lived inside the switch the attackers had compromised. A control on the same compute substrate as the attacker is a control the attacker can suppress. The defence is two tiers:
- Tier 1 — inside the switch. Routine throttling of individual cards and high-value bursts. Where most banks already operate.
- Tier 2 — out of band. Separate infrastructure, separate credentials, separate identity provider. Receives a copy of every authorisation request via a tap on the ISO 8583 bus. Applies a small set of high-cardinality controls — total dispense rate per BIN range, cross-country correlation per customer cohort, gross outflow against a daily ceiling per country. When breached, it issues a kill switch — a network block, an HSM-key-rotation trigger, an alert with a documented runbook.
The attacker who compromises the switch must also compromise the out-of-band tier to suppress the gate. The two systems on separate networks with separate admin paths make the second compromise materially more expensive than the first. The architecture is designed to make the FASTCash operational tempo fail on the second box before it succeeds on the first.
The Anomaly Detector That Watches the Network, Not the Account
Per-account fraud detection misses FASTCash by construction. Each of the 3,421 Senegalese withdrawals looked legitimate on its own — a valid card, sufficient balance, a customer baseline that included occasional large cash withdrawals. The per-transaction fraud score was low.
The signature was in the network of withdrawals — simultaneity across three cities, coincidence across ten countries, a burst against a defined cohort that previously had no obvious relationship. The detector that catches this operates at network level, on aggregate features the switch's per-transaction overlay doesn't consider:
- Count of cards from a BIN range cashing out within a defined geographic radius
- Ratio of cross-country to in-country withdrawals across a customer cohort over a sliding window
- Deviation of the current minute's authorisation rate from the same minute last week
The infrastructure sits downstream of the switch and the out-of-band velocity tier. Authorisation messages stream into a real-time analytics layer — Kafka or Kinesis on the bus, Flink or Spark Streaming as the processor, a feature store, a small set of detection models retrained nightly. The engineering investment is meaningful. It is also less than the cost of one FASTCash night, and it pays for itself the first time it fires.
Segmentation, the Tabletop, and What This Doesn't Solve
The unsexiest control closes the most attack surface. The card-management subnet should sit on a network island behind a hard firewall, with a small explicitly documented allowlist of inbound connections, no direct internet egress, and access only through privileged-access workstations that have no other use. The point is not to make the attacker's job impossible. The point is to make the lateral path narrow enough that the attacker's months of dwell consume more attention than they can hide.
The exercise for this quarter is a tabletop of the FASTCash scenario. Set the clock to 19:00 Friday. First alert at 19:14. By 19:35 the rate is double baseline and climbing. The on-call's runbook says: kill the issuance certificate at the HSM. He hesitates — killing the cert stops every legitimate ATM withdrawal at the bank. He needs an authority above his own. The escalation path is unclear at 19:35 on a Friday evening. Find the gaps before Q3 finds them for you.
These controls don't eliminate FASTCash. They don't defend against the social-engineering side of initial access, and they can't pull cash back out of an ATM that has already dispensed it. What they do is turn FASTCash from a six-figure-per-bank-per-night certainty into a contested operational problem. That contest is winnable.
The question to take to your team is not whether the bank has implemented the items on ngCERT's list. The question is whether each control runs at the layer FASTCash operates on — and if not, what the path is to move it to the right floor before Friday evening.
FAQs
Is FIPS 140-3 Level 3 enough for the HSM, or do we need Level 4?
Level 3 is the practical floor for production card-key storage and is what most Tier 1 African banks deploy. Level 4 adds environmental protections — tamper detection against power-supply variation, EMF analysis, drill resistance — that matter when the threat model includes physical access. Pick the level that matches your physical-security posture and document the choice. Do not deploy Level 2 on the theory that the data centre's locks are enough.
What does the cross-country anomaly infrastructure cost?
For a Tier 1 African bank operating in five to ten countries, $200K–$800K per year fully loaded — streaming bus, processor, feature store, model operations, SOC integration, and the two-to-four-engineer team that runs it. The cost is dominated by the team, not the infrastructure. Start with the in-region authorisation stream, prove alerting against a single country's data, then expand to cross-country correlation once the false-positive rate is operationally tractable.
Does this change for cloud-hosted issuer switches running on AWS or Azure?
The threat model is the same; the implementation surface shifts. Cloud-IAM credentials replace on-prem network access as the lateral-movement target, and the same privileged-access discipline applies. Cloud HSMs (AWS CloudHSM, Azure Dedicated HSM) provide FIPS 140-3 Level 3 — the key-management discipline now spans the bank's admin path and the cloud provider's operational path. Cloud-native network policy is easier to express precisely than equivalent firewall rules, but only if the team has the cloud-security maturity to use it correctly.
How does this map to CBN CSAT and NDPA?
CBN CSAT requires payment-system controls including segregation of duties, privileged-access management, and incident-response capability. The architecture above is the operational implementation of those requirements at the card-authorisation layer. NDPA Section 41–43 applies to the cross-border patient-data flows during a multi-country incident response — unavoidable in a ten-country operation. The combined regulatory expectation is that the bank can demonstrate the controls were in place, that they fired or failed in defined ways, and that affected customers were notified in compliance with NDPA.
Companion content
- Ten Countries, One Night: UBA, FASTCash, and the Pan-African Card-Authorization Heist — the DSI intelligence briefing on the threat-actor lineage and the January 30 night
- Agent Action Approval Gates — the human-in-the-loop pattern adjacent to the out-of-band velocity tier
- OPA for AI Agent Action Approval — the policy-decision-point pattern applicable to card-management-rule modification
- CBN CSAT Compliance Roadmap — regulatory grounding for these controls
How to engage
If your bank is running this advisory through its architecture review and you want a vendor-neutral read on where each control lands against your specific stack, talk to us at creativeminds.dev/contact. The cmdev card-authorisation diagnostic produces a prioritised gap list, a tabletop tuned to your subsidiary footprint, and a ninety-day remediation plan that maps to CBN CSAT and NDPA.