It is 08:14 on a Thursday morning at a Lagos Tier 1 bank. The payment-systems lead is at his desk with a printed copy of the ngCERT advisory that landed in his inbox on Wednesday afternoon. The advisory describes the UBA pan-African cash-out operation — the January 30 night, the ten countries, the 1.143 billion CFA francs, the privileged access to card-authorisation infrastructure that made the whole night possible. He has spent the morning so far doing what every payment-systems lead at every Nigerian Tier 1 bank is doing this week, which is running a quiet, unauthorised inventory of his own card-management subnet. Who has administrative access to the issuer switch. Which service accounts can modify card-management rules. When the last full audit of those accounts happened. How many of them are shared between teams. The answers he is getting do not let him close the printed copy of the advisory and move on to the next item in his queue.
The advisory's recommendations — tighter access to card-management systems, strengthened ATM security, real-time fraud detection, regular audit of card records, advanced threat-detection tools, routine security assessments, phishing training — are correct. They are also a control-list, which is what regulatory advisories must be, and they tell him what to do without telling him how to engineer it against the specific shape of the attack he just read about. The companion DSI briefing covers the lineage and the threat-actor side of the story. This piece is the engineering side — the controls 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 layer; the defence has to land where the rules are written.
- HSM-backed storage for card keys is the load-bearing primitive of the architecture. The key material that signs authorisation responses must live in a Hardware Security Module that the attacker cannot reach even with administrative access to the switch. Software-side key storage is the equivalent of the issuer switch trusting itself.
- Velocity controls must run at two tiers — one in the issuer switch, one out of band. The out-of-band tier sits on a separate system with separate credentials and the authority to override the switch's decisions. The attacker who compromises the switch must also compromise the out-of-band tier to suppress the velocity gate, and the architecture is designed to make the second compromise materially harder than the first.
- The anomaly detector that survives a coordinated burst has to correlate across customer accounts, across geographies, across subsidiaries, in near real time. Per-account fraud detection misses the FASTCash signature because each individual withdrawal looks legitimate. The signature is the simultaneity, and that signature only appears when the detector watches the network rather than the account.
- Network segmentation of the card-management subnet is the unsexy control that closes most of the attack surface. The issuer switch and card-management platform should sit on a network island with a hard firewall, no direct internet egress, no lateral path from the user-IT environment, and a privileged-access workstation as the only entry point. ngCERT's advisory implies this. This piece names it.
Where the Rules Actually Live
A useful starting point for any engineer reading the ngCERT advisory is to be specific about which piece of the bank's stack the attackers held in the UBA operation. When a customer dips a card at an ATM in Dakar, the ATM does not decide whether the withdrawal is authorised. The ATM is a thin client. It captures the card details and the PIN, formats an authorisation request in ISO 8583 — the message format every card-payment network in the world still speaks — and sends the request to the acquirer, which routes it to the card issuer's authorisation system. The issuer's authorisation system is the issuer switch. The switch is a specialised piece of banking infrastructure — typical vendors in the African market are ACI, FIS, Compass Plus, BPC, ProgressSoft, or the bank's own in-house build — and it holds the rules for what each card is allowed to do.
The rules live in the switch and in an upstream system that issues them to it, the card-management platform. The card-management platform is where new cards are minted, where existing cards have their parameters updated, where withdrawal limits are set, where status changes — active, blocked, pending replacement — are made. The platform pushes the relevant rule state down to the switch on a schedule and on demand. When an authorisation request arrives at the switch, the switch evaluates the request against the rules it currently holds, applies any fraud-detection overlay, and returns an authorisation response. If the response is approved, the ATM dispenses cash. If the response is declined, the card comes back without cash.
FASTCash compromises target the layer between the card-management platform and the switch — sometimes one, sometimes the other, sometimes both. Once the attackers hold administrative access to either system, they can modify the rules for chosen card ranges — raise daily limits, disable velocity gates, override country restrictions, suppress fraud flags. From the ATM's point of view, every authorisation response remains correctly formatted and legitimately signed. From the customer's point of view, the bank's own systems have decided to dispense the cash. The ATM is not broken. The switch is doing exactly what its current rules say to do. The current rules are what was modified, and the modification is the attack.
What "Privileged Access" Means When You Already Have It
The ngCERT advisory's language — gained privileged access to card-authorisation infrastructure, allowing them to manipulate transaction controls — describes precisely the access level the attackers held in the UBA operation. The phrase covers a wide range of specific privileges. At minimum, the attackers had write access to the card-management platform's rule database, with the authority to modify rule sets for chosen card ranges without those modifications triggering an alert that human reviewers would investigate. More likely they also had read access to the customer database, which they used to select the 91 accounts whose cards would be re-parameterised for the cash-out night. Probably they had access to the switch's administrative console, to confirm that the modified rules had propagated and to make last-minute adjustments. Possibly they had access to the audit-log infrastructure, to suppress or alter the log entries that would otherwise have shown the rule modifications.
The path to that level of access in a typical Tier 1 bank is well-documented in the broader FASTCash research and in the CISA AA20-239A alert. The initial compromise is a phishing email landing in a corporate IT inbox — frequently a developer or a sysadmin whose machine has a path into the broader payment-systems environment. From the initial foothold, the attackers move laterally — through shared file shares, through reused credentials, through service accounts that were over-privileged for convenience. Eventually they reach the card-management subnet. They harvest credentials from the privileged-access workstation that the bank's payment-systems engineers actually use to administer the platform. They sit. They watch the rhythm of legitimate administrative actions for weeks, sometimes months, to understand what normal looks like. Then they make their modifications in a way that mirrors the cadence of normal administration, and they wait for the operational night they have pre-positioned the mule network to deliver.
The architectural lesson is that privileged access is not a binary the bank either has or does not have inside its environment. It is a layered surface, with the most sensitive layer — the rules that decide which card transactions to authorise — sitting on infrastructure that ought to be defended differently from the rest. The defence is the subject of the rest of this piece.
The HSM Is the Wall the Switch Is Not
The load-bearing primitive of the defended architecture is the Hardware Security Module that holds the card keys — the cryptographic material that signs the authorisation responses the issuer switch returns to the acquirer. In a well-engineered Tier 1 bank, the HSM is a physical appliance, FIPS 140-3 Level 3 or Level 4 certified, sitting in a tamper-protected enclosure in the bank's data centre. The HSM holds the card-issuing keys, the message-signing keys, and the PIN-translation keys. It exposes them through a narrow interface that lets the switch request signatures but never lets the switch — or anything else — extract the key material itself.
The reason this matters in the FASTCash context is that the attackers in the UBA operation held administrative access to the switch. Administrative access to the switch should not equal access to the cryptographic material the switch uses to sign authorisation responses. The HSM enforces that separation in hardware. An attacker who has compromised the switch's software environment can request signatures from the HSM — the switch needs to be able to do that to sign legitimate authorisation responses — but cannot extract the signing key. The blast radius of a switch compromise is bounded by the scope of what an attacker can ask the HSM to sign in the time window between the compromise and detection.
The architectural failures we see in mid-market African banks tend to be one of three patterns. The first is HSM-bypass — the switch was originally built with HSM integration in mind, but at some point during operations a software-side key store was added for "performance reasons" or "fallback during HSM unavailability." The fallback path becomes the production path, and the HSM stops being load-bearing. The second is shared-credential misuse — the HSM is correctly integrated, but the administrative credentials that govern HSM configuration are shared between the switch operations team and the broader payment-systems team, and an attacker who reaches the broader team's credentials can re-key the HSM rather than extract from it. The third is operational drift — the HSM is correctly integrated and the credentials are correctly segmented, but the firmware is years out of date, the key-rotation schedule has been silently abandoned, and the audit log of HSM operations has been turned off because nobody on the team understands how to read it.
Each of these failures degrades the load-bearing primitive into a checkbox primitive. The HSM is on the architecture diagram and the attacker walks around it.
Two Velocity Gates, One Out of Band
The control that would have caught 3,421 coordinated withdrawals across three cities in a single night is a velocity gate that watches the rate of authorisation responses against any defined population of cards. The Senegalese leg of the UBA operation pushed approximately 1,140 withdrawals per Senegalese city through the night. A velocity gate set to a sensible threshold — say, ten times the historical maximum hourly cash-out rate across that customer range — would have caught the burst within the first thirty minutes.
The reason the velocity gate did not fire — assuming the bank had one configured — is that it lived inside the issuer switch the attackers had compromised. A control that runs on the same compute substrate as the attacker is a control the attacker can suppress. The defence is to run velocity at two tiers — one inside the switch where it does the routine work of throttling individual cards and bursts of high-value transactions, and one out of band on a separate system with separate credentials and the authority to override the switch's authorisation responses.
The out-of-band tier sits on its own infrastructure. It receives a copy of every authorisation request and the switch's response, in near real time, through a tap on the ISO 8583 message bus or through a stream the switch emits to a separate broker. It applies a small set of high-cardinality controls — total dispense rate per minute per BIN range, cross-country dispense correlation per customer cohort, gross outflow against a daily ceiling per country. When the out-of-band tier's thresholds are breached, it issues a kill switch — a network-level block, a key-rotation trigger to the HSM that invalidates the active card-issuance certificate, an alert to the on-call team with a documented runbook to follow.
The attacker who compromises the switch must also compromise the out-of-band tier to suppress the velocity gate. The two systems must be on separate networks, have separate administrative identity providers, separate privileged-access workstations, separate audit-log destinations. The cost to the attacker of compromising both is meaningfully higher than the cost of compromising one — not because the second system is twice as hard to compromise individually, but because the lateral movement path between the two has to be discovered and exploited as a separate phase of the operation. The architecture is designed to make the second compromise a long enough operation that the operational tempo of the FASTCash playbook fails on the second box before it succeeds on the first.
The Anomaly Detector That Cares About Twenty Countries at Once
Per-account fraud detection — the traditional model where every customer's transaction history is scored against their own behavioural baseline — misses the FASTCash signature by construction. Each of the 3,421 Senegalese withdrawals, taken individually, looked like a legitimate cash withdrawal against a legitimately authorised card with sufficient available balance. The customer baselines for the 91 affected accounts had been seen to include occasional large cash withdrawals before. The fraud-detection score on any single withdrawal was low.
The signature was in the network of withdrawals — the simultaneity across three cities, the coincidence across ten countries, the burst against a defined customer cohort that previously had no obvious relationship. The anomaly detector that catches this has to operate at network level — correlating authorisation patterns across customer accounts, across geographies, across subsidiaries, in near real time. The features that matter are not the per-transaction features that the issuer switch's built-in fraud overlay considers. The features are aggregate — count of cards from a given 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 and the same minute last year.
The data infrastructure to support this lives downstream of the switch and the out-of-band velocity tier. The authorisation messages stream from the switch into a real-time analytics layer — Kafka or Kinesis as the bus, Flink or Spark Streaming as the processor, a feature store for the aggregate features, a small set of detection models that score the aggregate features against historical baselines. Production banks running this pattern operate it at sub-second latency end-to-end, with the detection models retrained nightly against the previous day's authorisation corpus. The cost is meaningful — the data infrastructure is itself a meaningful engineering investment, the model maintenance is an ongoing operational tax, the false-positive rate has to be managed against the operational cost of false declines.
The cost is also less than the cost of one FASTCash night. The Senegalese leg alone was two million dollars. The full ten-country damage is multiples of that. The data infrastructure that detects the next operation in the first fifteen minutes pays for itself the first time it fires.
Segmentation Is Not Optional
The unsexiest control on this list is the one that closes the largest share of the attack surface. The card-management platform and the issuer switch should sit on a network island. There is no business reason for the corporate IT environment to have any direct network path to the card-management subnet. There is no business reason for the card-management subnet to have any direct internet egress. There is no business reason for a developer's laptop to be one VPN hop away from administrative access to the switch. Each of these reasons gets quietly violated in practice because the alternative is operationally awkward, and the awkwardness compounds over time until the path that should not exist exists, and an attacker who lands in the corporate IT environment has a route to the switch.
The defended architecture isolates the card-management subnet behind a hard firewall with a small, explicitly documented allowlist of inbound connections — the upstream from the core banking platform, the downstream to the switch, the management connection from a small set of privileged-access workstations, the audit-log destination, and nothing else. Outbound network access from the subnet is denied at the network policy layer except for the same small set of destinations. Administrators reach the subnet through privileged-access workstations that have no other use, no browser, no email client, no developer tools — a Windows or Linux image whose only purpose is to administer the card-management platform. The privileged-access workstations themselves require multi-factor authentication on every administrative session, ideally tied to a hardware token that does not leave the operations team's secure room.
The point of this discipline is not to make the attacker's job impossible. The point is to make the lateral movement path from initial foothold to card-management compromise visible — to give the bank's threat-hunting team and SOC a small enough set of paths to watch that an anomalous administrative session shows up before the operational night arrives. The FASTCash dwell time of months between initial access and cash-out is, in the attacker's view, the budget they have to find the path. The defender's job is to make the path narrow enough that the attacker's months of dwell consume more attention than the attacker can hide.
What ngCERT's Recommendations Get Right, and What They Don't Reach
The June 25 advisory is correct in the controls it names. Tighter access to card-management and payment systems is correct, and is what the network-segmentation discipline above operationalises. Strengthened ATM security is correct, although the ATM is the wrong layer for this attack and the recommendation is best read as a reminder that the broader ATM operational environment — the dispenser firmware, the on-machine logging, the local network segmentation — needs hygiene regardless. Improved real-time fraud detection is correct, and the cross-account network-level anomaly architecture above is its concrete implementation. Regular audits of card records and network activity are correct. Advanced threat-detection tools are correct. Routine security assessments are correct. Staff training on phishing and insider threats is correct, and is the initial-access defence on which the rest depends.
What the advisory does not reach, because regulatory advisories generally cannot, is the architectural language of how each control fails when it is implemented at the wrong layer. Real-time fraud detection that runs inside the same issuer switch the attacker has compromised is not real-time fraud detection; it is real-time fraud detection theatre. Tighter access to card-management systems that does not include hardware-rooted network segmentation and HSM-protected key material is access control without enforcement. Routine security assessments that test the perimeter but never reach the card-management subnet are assessments of the wrong perimeter. The advisory's control list is a checklist of what to do. The engineering question is whether the implementation lands at the layer where the FASTCash attack actually operates, or one layer above, or one layer below.
This is the gap most pan-African bank implementations fall into. The investment was real; the layer was wrong.
The Tabletop Every Pan-African Bank Should Run This Quarter
The exercise to run this quarter is a tabletop of the FASTCash scenario against the bank's own card-management subnet. The scenario is the UBA operation. Set the clock to 19:00 on a Friday evening. The bank's SOC receives the first alert at 19:14 — an unusually high authorisation rate against a defined card cohort. The on-call payment-systems engineer is reached at 19:22 and confirms that the authorisation rate is real, against real cards, and the responses are signed legitimately. By 19:35, the rate is double the baseline, climbing. The on-call's runbook says: kill the issuance certificate at the HSM. The on-call hesitates. Killing the certificate stops every legitimate cash withdrawal at the bank's ATMs for the duration of the response. The on-call needs an authority above his own to make the call. The bank's escalation path is unclear at 19:35 on a Friday evening.
Run the tabletop. Find every place the architecture has a gap. The most likely places to find gaps are: the runbook does not exist; the runbook exists but specifies an action the on-call engineer cannot execute alone; the action requires a credential or an authority that takes too long to assemble; the kill-the-certificate decision is technically reversible but operationally catastrophic; the cross-country coordination between subsidiaries during an incident has no rehearsed protocol; the legal and regulatory notification flow has no playbook for the ten-country case. Each of these gaps is a place to invest before Q3.
The pan-African banks that run this tabletop seriously will be unable to enjoy the answers they produce. The exercise is unpleasant by design. The alternative — running it for real, against a real attacker, with the press already aware that 1.143 billion CFA francs walked out of the network last Friday — is unpleasant differently.
What This Architecture Does Not Solve
The controls above do not eliminate the FASTCash threat. They make it operationally expensive, and they shorten the dwell time between attacker reach and defender detection. They do not solve the social-engineering side of the initial access — phishing is still effective, insider-threat is still real, third-party-vendor compromise is still a path. The architecture above assumes some form of initial access into the corporate IT environment and is designed to make the lateral movement from there to the card-management subnet expensive enough that the attacker either gives up or is caught.
The controls do not solve the cash-mule logistics side either. Even if the bank detects the burst at the fifteenth minute and kills the certificate at the seventeenth, the seventeen minutes' worth of withdrawals have already happened in physical cash. The recovery of those withdrawals is downstream — law enforcement, the mule network arrests, the painstakingly slow tracing of cash through informal value-transfer systems. The architecture cannot pull cash back out of an ATM that has already dispensed it. The architecture can compress the dispense window. The remainder is a law-enforcement problem.
What the controls do solve is the question of whether the bank's own engineering and SOC discipline can shape the outcome before it becomes a headline. The defended architecture turns FASTCash from a six-figure-per-bank-per-night certainty into a contested operational problem. That contest is winnable. The next UBA-scale operation is a question of which African bank's name appears in the next ngCERT advisory and how prepared that bank was to read its own card-authorisation environment in the days before.
If your bank is running this advisory through its weekly architecture review tonight, and you are the engineer who has to answer the question of which control runs where, the question to take to your team is not whether the bank has implemented the items on the advisory's list. The question is whether the layer at which each control runs is the layer at which FASTCash operates — and if it is not, what the path is to move the control to the right floor of the building before Friday evening.
FAQs
How much of this architecture is already deployed at a typical Tier 1 Nigerian bank?
Most Tier 1 Nigerian banks have an HSM, a card-management platform, an issuer switch, a fraud-detection overlay, and a SOC. Whether those components are wired together as a defended FASTCash-resistant architecture is the question. Common gaps we see: HSM-bypass paths in production, single-tier velocity controls running only inside the switch, fraud-detection scored per-account rather than per-cohort, card-management subnet sharing network infrastructure with the broader corporate environment, and incident-response runbooks that have not been exercised against a coordinated multi-subsidiary scenario. The components exist; the architecture they form is the work.
Is FIPS 140-3 Level 3 enough for the HSM, or do we need Level 4?
FIPS 140-3 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 variations, EMF analysis, drill-resistance — that matter when the threat model includes physical access to the HSM enclosure. For a bank whose HSM lives in a guarded data centre with physical access logging, Level 3 is defensible. For a bank whose data centre is shared with non-banking tenants or has weaker physical-access controls, Level 4 closes the gap. The advisory line is: 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 is the typical cost of the cross-country anomaly-detection data infrastructure?
For a Tier 1 African bank operating in five to ten countries, the cross-country anomaly infrastructure runs in the range of $200,000 to $800,000 per year fully loaded — including the streaming bus, the processor, the feature store, the model training and operations, the SOC integration, and the two-to-four-engineer team that operates it. The range is wide because the cost is dominated by the engineering team rather than the infrastructure itself. The implementation pattern most banks land on is to start with the in-region authorisation stream, prove the alerting works against a single country's data, then expand to cross-country correlation once the false-positive rate is operationally tractable.
How does the out-of-band velocity tier interact with the bank's existing fraud-detection overlay?
The existing fraud-detection overlay in most Tier 1 banks runs inside the issuer switch and scores individual transactions against per-account baselines. The out-of-band velocity tier operates above that — looking at aggregate patterns across the network, not individual transactions. The two layers are complementary and run on separate substrates. The fraud overlay catches the long tail of per-account anomalies (lost card, unusual location, atypical merchant). The out-of-band tier catches the coordinated network-level pattern the per-account overlay misses by construction. Both should be in production; neither replaces the other.
What is the regulatory grounding for these controls under CBN CSAT and NDPA?
The Central Bank of Nigeria's Cybersecurity Framework — CBN CSAT — requires payment-system controls including segregation of duties, privileged-access management, and incident-response capability in regulated financial institutions. The architecture in this piece is the operational implementation of those requirements at the card-authorisation layer. NDPA 2023 applies to the personal data exposed when 91 customer accounts had their card-management records modified. NDPA Section 41–43 cross-border transfer applies when the affected customers' data crosses jurisdictional boundaries during the incident response, which in a ten-country operation is unavoidable. 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 the affected customers were notified in compliance with the relevant data-protection laws. The architecture above is what produces that demonstration.
What about cloud-hosted issuer switches — does this change for banks running ACI or BPC on AWS or Azure?
The cloud-hosted variant of an issuer switch raises the architectural bar in two ways and lowers it in one. It raises the bar on identity and access management — cloud-IAM credentials replace on-prem network access as the lateral-movement target, and the same privileged-access discipline applies. It raises the bar on HSM integration — cloud HSMs (AWS CloudHSM, Azure Dedicated HSM) provide FIPS 140-3 Level 3 protection but require careful key-management discipline across the bank's own administrative path and the cloud provider's operational path. It lowers the bar on network segmentation in the sense that cloud-native network policy and security groups are easier to express precisely than equivalent on-prem firewall rules — but only if the team has the cloud security maturity to use them correctly. The threat model is the same. The implementation surface shifts.
Companion content
- Ten Countries, One Night: UBA, FASTCash, and the Pan-African Card-Authorization Heist — the DSI intelligence briefing on the threat-actor lineage, the January 30 night, and what the next quarter looks like
- Agent Action Approval Gates: Designing the Human-in-the-Loop That Scales — the human-in-the-loop pattern adjacent to the out-of-band velocity tier
- OPA for AI Agent Action Approval: Policy-as-Code for Agent Guardrails — the policy-decision-point pattern applicable to the card-management-rule modification workflow
- IAM for AI Agents: Delegation and the Principal-of-Record Chain — the audit-chain discipline the card-management-rule modification audit trail must replicate
- CBN CSAT Compliance Roadmap — the regulatory grounding for these controls in Nigerian Tier 1 banking
- African Enterprise Cloud Security Failures — broader pattern of African enterprise security gaps this piece sits inside
How to engage
If your bank is running the ngCERT advisory through its weekly architecture review and the answer to which layer does each control land on is not as confident as the room would like, talk to us at creativeminds.dev/contact. The cmdev card-authorisation diagnostic walks the architecture in this piece against your specific card-management platform, issuer switch, HSM deployment, and SOC posture; it produces a prioritised gap list, a tabletop exercise tuned to your subsidiary footprint, and a ninety-day remediation plan that maps to CBN CSAT and NDPA reporting requirements. We do not resell the platforms — ACI, FIS, Compass Plus, BPC — and the diagnostic is vendor-neutral on which platform you currently operate. The architecture is the same regardless of vendor; the implementation gaps are what we land on.