How Capitec Secures Your Money: Real Answers to Real Questions

Capitec secures customer money through layered defenses including SIM-swap detection, transaction limits, real-time fraud monitoring, and strict internal access controls that limit what employees can see or do. Customers can also freeze accounts instantly via the app. No system is perfect, but combining technology, behavioral detection, and rapid response significantly reduces exposure to common fraud threats.

Andrew Baker · May 2026

I get asked a lot of questions about how Capitec secures its customers’ money. Not in the abstract, but the real ones: what happens if someone swaps my SIM, can someone drain my account while I am on hold with the fraud line, how do you stop someone inside the bank from abusing their access? These are good questions and they deserve real answers, not marketing copy, which is what this post is my attempt to provide, honestly, in plain language, without hiding behind complexity.

It is pretty nerve-racking talking about this topic, because nothing is perfect. But not talking about it is essentially telling clients that my discomfort outweighs their concerns, and that is not fair.

The single biggest shift in how we think about fraud and security at Capitec was the day we stopped asking what the client did wrong, or how we could educate them to be more careful, and started asking what we could do better, even if the answer meant throwing out half our technology stack and starting again. That change in orientation is behind most of what follows in this post.

Before I get into the substance of this post, let me address something directly. When you write about security architecture in plain language, you should expect some responses to say you are answering the wrong question. That is a predictable move and you should see it for what it is: an attempt to subvert a clean message about technology and client protection by framing the goalposts as being in the wrong place. There are many questions in this space and I work actively on fraud architecture at Capitec. I know what our numbers show. We are the only South African bank with demonstrably decreasing fraud losses, and we have outstanding realtime interception capability for mule accounts that I have not even touched on here because it is an article in its own right. So if this post did not answer your specific question, do not mistake that for an absence of answers. We have them, they are good, and they are backed by the data. This article was always a specific article, not every article, and I am comfortable with that distinction.

1. Why did Capitec get rid of OTPs, and what does that mean for SIM swap fraud?

We moved away from OTP-based authentication years ago, not because it was inconvenient but because it is fundamentally unsafe, and SIM swap fraud is exactly why.

An OTP, a one-time password sent to your phone via SMS, assumes that your SIM card is in your hands and your hands only. In South Africa, SIM swap fraud is industrialised, with criminals routinely social-engineering mobile network operators into transferring a victim’s number to a SIM they control. Once they have the number, they have the OTPs, and the entire security layer collapses.

SIM swap is one of the most common attack vectors in South African banking, and our response to it was architectural rather than incremental: we simply decided not to trust SIMs. Your SIM is controlled by a mobile network operator, and mobile network operators have been successfully social-engineered thousands of times. Any security architecture that places meaningful trust in SIM ownership is building on an unstable foundation, and we made a deliberate decision years ago not to do that.

Instead of OTPs, enrollment and high-risk actions require a biometric selfie match verified against the Department of Home Affairs image database using proprietary matching algorithms, including full liveness detection specifically built to distinguish a real person from a photograph, a video replay, or a synthetic image. When you enroll a new device on Capitec, you are not authenticating via SMS but via a live biometric match against a government identity record. A SIM swap gives an attacker your phone number but not your face and not the ability to pass a liveness check, which means a compromised phone number gives an attacker nothing useful in our system.

If any credential is reset, including your PIN, the biometric verification happens only after a multi-hour enforced cooldown period that is neither configurable nor bypassable, and exists specifically to prevent an attacker from using a freshly compromised credential to immediately access high-value functions. We also offer Contact Lock, which allows customers to add further restrictions on device binding and account access using device fingerprinting to ensure that the app cannot be easily installed on an attacker’s device.

2. Can someone drain my account even if they get into my app?

It depends on how they got in, and that distinction matters.

If an attacker has your PIN and access to an authenticated session and they are paying an existing beneficiary you have paid before, then yes, they can move money up to the balance available. The controls we have built are not designed to stop a fully authenticated session doing something that looks like normal behaviour; they are designed to stop attacker behaviour that looks different from yours, and I am not going to pretend otherwise.

Where our layered controls make a significant difference is in the scenarios that actually dominate fraud at scale: payments to new or suspicious beneficiaries, unusual velocity, and accounts being targeted as mule destinations. If a payment is going to an account we do not recognise or flag as suspicious, it does not simply process or block but is proxied and paused, meaning we hold it before it clears and run analysis on it before deciding what happens next.

Plain English: suspicious payments do not go straight through. They wait while we look at them.

That analysis is where the architecture gets interesting, because what we built is not a simple rules engine checking your transaction against a list but a graph traversal across billions of payments. The system combines Memgraph, an in-memory graph database, with two purpose-built beneficiary databases. The first is the user beneficiary database, which captures each client’s relationship with the accounts they pay. The second is the global beneficiary database, which captures the same payment relationships from the opposite direction, from the beneficiary’s perspective across every Capitec client who has ever paid them. The two databases hold the same underlying payment data laid out twice in deliberately opposite orientations, and that design choice matters because it gives us optimised access patterns to traverse the graph in either direction without expensive queries, which is exactly what you need to do realtime graph analysis across millions of clients and millions of beneficiaries at transaction speed. Both databases run as read replicas, meaning the fraud analysis draws on them without competing with write traffic from live transactions and without any blocking contention between the system looking for fraud and the system processing payments.

What this means in practice is that when your payment arrives, we are traversing the network around the destination account in real time, looking at how many other Capitec clients have paid that account, over what time window, in what amounts, and whether that pattern matches the signature of a mule account collecting funds from multiple victims simultaneously. A destination account that looks clean from your individual perspective can look very different when you see it from the beneficiary perspective across the whole network, and this endpoint and beneficiary velocity monitoring means that even if a single transaction looks innocent in isolation, the broader pattern around the destination account can still trigger an intervention. The first time you pay an account you have never paid before, that transaction also receives elevated scrutiny specifically.

If the app has been recently installed on a device, limits on certain products automatically reduce for a period, because a new install on an unfamiliar device is a risk signal we treat accordingly. Our card systems use risk-based algorithms and can force a 3DS step-up authentication that pauses the transaction and asks you to verify it directly in our app when the risk profile warrants it; these pauses are deliberate behavioural interventions, because Authorised Push Payment fraud relies on panic and urgency and slowing the process down breaks that dynamic.

At the core banking level, hard limits exist independently of the app and cannot be overridden by an authenticated session presenting valid credentials. Notice account withdrawals require a biometric selfie at the point of withdrawal rather than just an authenticated session, the maximum that can be withdrawn digitally is deliberately constrained, and those limits are reviewed and adjusted regularly based on the current fraud landscape.

The scenario that concerns us most at the device level is malware, because malware gives an attacker a presence on the same device you are authenticating from. If malware is detected on your device, we immediately block the account. Our in-house malware detection capability has had zero breaches since going live earlier this year, and while the attackers are not giving up, so far the detection is holding. More on this in section 8.

3. If I call the fraud line while transactions are happening, can you actually stop them in time?

Yes, and the reason matters because the critical architectural question is not whether we can stop fraud but where in the payment pipeline our intervention sits. A transaction moves through an authorisation layer before it settles, and that window is the only moment a hold is possible; once settlement occurs, reversal requires cooperation from the receiving institution and is never guaranteed.

When a Capitec consultant initiates an account freeze, that action connects directly to the authorisation layer in real time without travelling through a ticketing system or waiting for an escalation workflow, meaning the account state change takes effect before the next transaction instruction is evaluated.

Plain English: if you call us while an attack is in progress, our consultant’s freeze action is faster than the next transaction, not slower.

We also operate automated presettlement intercept capability, meaning transactions flagged by our fraud detection systems can be held before they clear without requiring a human to trigger the hold; the human review follows, but the hold does not wait for it. In April 2026 we rolled out Pulse, a real-time AI support system that, when a client contacts the fraud line via the app, instantly reconstructs their recent app activity including failed transactions and security triggers and feeds that context to the agent before the conversation even begins.

One honest qualification: fraud models are probabilistic, and a novel attack pattern that has not yet appeared in our training data will not be caught until the models learn it. That is true of every institution running this kind of system, and anyone claiming otherwise is offering reassurance rather than accuracy.

4. What about criminals who call and pretend to be Capitec?

Vishing, voice phishing, is now one of the most damaging fraud vectors in South African banking, and it is important to be honest about why it is hard to stop. The technical controls described in this post are designed to detect and interrupt attacker behaviour, but vishing bypasses them entirely by convincing you, the legitimate account holder, to perform the transaction yourself.

The script is consistent: a caller claims to be from the Capitec fraud team, tells you there is suspicious activity on your account and that your money needs to be moved urgently to a “safe account” while they investigate, creates panic and urgency, and keeps you on the line while the account the money is moved to turns out to be theirs. The reason this works is that a transaction you initiate yourself, to a beneficiary you add yourself, authenticated with your own credentials, looks from a system perspective like a normal transaction. Our fraud controls are built to detect behaviour that differs from yours, and when you are the one performing the behaviour, that signal disappears.

We have built two specific countermeasures into the app. The first is that we block certain high-risk transactions while you are on an active phone call, so if you are on the phone and attempt to add a new beneficiary or make certain payment types, the system intervenes. The second is Call Verify, which appears on the login screen and tells you in real time whether Capitec is currently calling you and if so who the caller is; if someone claims to be from Capitec and Call Verify shows no active Capitec call, you are not talking to Capitec.

The honest admission is that these controls are not complete. We still see clients who move money themselves despite these interventions, because the social engineering is sophisticated enough to override their own judgement in the moment, and a caller who has already established fear and urgency can talk someone through dismissing an on-screen warning. We are also seeing a specific attack pattern targeting business banking clients, where a fake SMS about a fraudulent transaction prompts the client to perform a login selfie or a payment selfie that the attacker then harvests. We are engineering responses to both of these vectors and will write about them when the work is done.

The most important thing I can tell you is this: Capitec will never call you and ask you to move money to a safe account. If your account were actually compromised, we would block it rather than ask you to move the money first, so if anyone calls you saying otherwise, hang up and call us back on the number in the app.

Note: our Fraud team recently went live with an in app call back request for when we are trying to get hold of you. You can also dial our Fraud team directly from within our App (top right telephone icon after logging in).

Plain English: Capitec NEVER needs you do do ANYTHING to “protect your money” or “issue a refund”.

5. How do you stop someone getting real-time intelligence about my account?

This question matters more than most people realise. A criminal who knows your exact balance right now is not working from old stolen data but has live access to something, and that something is either a compromised system endpoint, an internal actor, or a misconfigured data pipeline. Before explaining what we do about those three things, it is worth being honest about a structural vulnerability that exists across the entire South African banking industry: SMS.

SMS is transmitted unencrypted across the mobile network operator’s APN, the Access Point Name, which is the gateway between the mobile network and the internet. When a bank sends you a transaction notification or an OTP by SMS, that message travels in plaintext through infrastructure owned and operated by a mobile network operator, passing through switches, routers, and aggregation points that the bank does not control and cannot audit. At any of those points, an attacker with access to the network infrastructure, whether through a rogue employee, a compromised network node, or a lawful intercept system being abused, can read that message in full.

SMS interception does not require sophisticated equipment. An SS7 attack, exploiting weaknesses in the Signalling System 7 protocol that underpins global mobile telephony, allows an attacker with access to the SS7 network to intercept messages and calls sent to any phone number in the world, silently, without the recipient knowing. Purpose-built IMSI catchers, which mimic cell towers to intercept nearby mobile traffic, are commercially available, and nation-state actors and sophisticated criminal groups have been using both techniques for years.

Plain English: when a bank uses SMS to send you your transaction amount, they are hoping that nobody intercepts it between their server and your phone. Hope is not a security control.

The precision of the intelligence leaks described in the IOL investigation, where callers already knew the exact amount of a transaction that had just landed, is entirely consistent with SMS interception and does not require a compromised internal system; it requires only access to the unencrypted notification that fired when the money arrived.

This is one of the reasons we do not use SMS for transactional notifications that carry financial detail. But I want to be honest about something broader, because the bank is not the only place where your financial data leaks. When you share a bank statement to apply for a loan, that PDF often travels by email, and while email is encrypted in transit between modern servers, the servers themselves store the message in plaintext and email threads are routinely forwarded, CC’d, printed, and left in inboxes. When a broker, a landlord, or a vehicle finance company asks for three months of statements, they are asking you to hand over a detailed map of your financial life to a party whose data security you have no way of assessing. The list of vectors is long: shared PDFs, unsecured email attachments, third party credit bureau queries, loyalty programme integrations, insurance assessments. Any system that receives your financial data and does not encrypt it at rest and in transit is a potential source of the kind of precision intelligence that makes a social engineering call convincing.

We cannot control what happens to your data once you share it with a third party, but we can control what data our own systems emit and what access our own staff have to live transaction data, and we address both.

Capitec operates a zero trust network using Zscaler for ZTNA, Zero Trust Network Access, which means no system, no user, and no device is trusted by default even inside our own network. Every request is verified every time, there is no inside-the-firewall where things are automatically trusted, and everything has to prove it belongs constantly. On internal staff access, we operate full network segregation and run agentic behavioural analysis across everything our staff do on our systems, not logging for retrospective review but active pattern matching that looks for deviations from normal behaviour in real time; if we detect abuse, we act immediately, and we have been and will continue to be public when that happens. On data pipelines and third party integrations, we apply data minimisation principles to what third party systems receive, because a notification service needs to know that a notification should fire but does not need to know the transaction amount, and excess data sitting in the wrong place is an exploit waiting to happen.

6. How do you stop someone inside Capitec abusing their access?

This is the question most banks answer with “we have role-based access controls,” which is the security equivalent of saying “we have a lock on the door.” It is necessary but nowhere near sufficient.

We operate an industry-leading Privileged Access Management solution and are actively migrating to a zero standing privilege architecture, which means that elevated access to sensitive systems is not a permanent credential any employee carries but is granted for a specific task, for a specific time window, and automatically revoked when that window closes.

Plain English: nobody has the keys to everything, all the time. Access is issued for a reason and taken back when that reason is gone.

Zscaler enforces that segregation at the network level, not just the application level, meaning an employee cannot reach a system they have no business reaching regardless of what credentials they hold. A customer-facing consultant can also see which consultants have previously viewed a specific account, which is intentional, because we then run agentic analysis that correlates that access history against subsequent fraud events on those accounts; if a consultant’s access pattern correlates with fraud outcomes, that signal is visible and acted on.

Plain English: if someone inside the bank looks at your account before something bad happens to it, we will find that connection.

7. How does Capitec protect the app itself from being tampered with?

The Capitec app uses mTLS, mutual Transport Layer Security, for all communication between your device and our systems, meaning both your device and our servers verify each other’s identity before any data moves. A fake server cannot impersonate Capitec to your app and a fake app cannot impersonate your device to our servers, which prevents man-in-the-middle attacks even on a malicious public WiFi hotspot where an attacker is sitting between your phone and the network.

We also use nonces, a number used once, in our transaction flows, where every transaction request contains a unique value that can only be used a single time. If an attacker intercepts a transaction and tries to replay it, the nonce has already been consumed and the replayed request is rejected, which closes off an entire class of replay attacks where a valid transaction is captured and resent to move money a second time.

8. What about malware on my device?

Malware on a customer’s device is one of the most serious threats in mobile banking because it sits on the same device the customer is authenticating from. We built our own malware detection capability in-house rather than relying entirely on third party solutions, because the threat landscape evolves faster than commercial product release cycles and we need to move at the speed of the threat; that capability has not had a single breach since going live earlier this year.

This does not mean you should be careless about device hygiene. Keep your operating system updated, do not install apps from outside official app stores, and do not grant accessibility permissions to apps that do not need them, because accessibility permissions are the primary mechanism malware uses to overlay fake screens on top of banking apps and intercept your credentials.

Plain English: if an app you downloaded from somewhere other than the Play Store or App Store asks for accessibility access, decline it and delete the app immediately.

9. What about malware on our devices?

The same threat exists on the other side of the connection. Our staff operate on enterprise endpoints, and a compromised endpoint inside our network is a fundamentally different risk profile from a compromised customer device, because an attacker with a foothold on an internal machine is not trying to drain one account but to move laterally, escalate privilege, and reach something much more valuable.

We run EDR, Endpoint Detection and Response, across our enterprise estate. EDR is not antivirus: antivirus matches files against a list of known bad signatures, whereas EDR watches what processes actually do, what they read, what they write, what they call, what they connect to. A piece of malware that has never been seen before will not match a signature list, but it will behave like malware, and EDR catches behaviour.

The part that actually matters is the response half of the name, because detection without automated response means a human has to see the alert, interpret it, and act on it, which takes minutes at best while a sophisticated attacker operating at machine speed can do significant damage in minutes. Our EDR is configured to respond automatically, isolating the endpoint and killing the process to contain the blast radius before a human has even opened the alert. The honest part is that automated response does not have context; it has rules and applies those rules without context, so it will occasionally get it wrong.

We took an EDR outage because a legitimate process was exporting registry keys as part of a routine operation which, to our EDR rules, looked like credential harvesting, causing the automated response to kill our core banking database. That was the “correct” action given what the rules could see, and from the outside the result was an outage rather than a breach. That is the deliberate tradeoff: a system aggressive enough to stop a real attack will occasionally stop something legitimate, and a system calibrated to never cause disruption is not calibrated aggressively enough to stop a determined attacker. We tune those rules continuously, and incidents like the registry export feed directly back into that tuning, because the goal is not zero false positives but a response posture where the cost of a false positive, an unexpected outage, is lower than the cost of a false negative, a real attack that got through.

There is a second EDR risk that has nothing to do with our own rule tuning. The CrowdStrike outage in 2024 demonstrated what happens when an EDR vendor ships a faulty update to an agent running at kernel level across millions of Windows endpoints simultaneously: the machines did not get attacked but got bricked by their own security tooling, with eight and a half million Windows devices going down in hours and hospitals, airlines, banks, and emergency services losing access to systems that were otherwise completely healthy.

The reason that class of outage did not affect Capitec the way it affected others comes down to an architectural decision we made before that event. We have been systematically moving away from legacy operating system deployments toward managed services and containers, using RDS for database workloads, EKS for containerised applications, and equivalent managed primitives across our infrastructure stack. Managed services of this kind do not expose their underlying operating system to anyone: you consume the capability, not the OS, and because the OS is not exposed there is no attack surface for an EDR agent to protect, which means there is no EDR agent to receive a faulty update and no kernel-level process to go wrong when one arrives.

Plain English: a significant portion of our infrastructure simply cannot be taken down by a bad EDR update, because that infrastructure does not have an operating system surface for EDR to touch.

This is not a security compromise but a security improvement, because the attack surface that EDR exists to protect is reduced rather than merely covered, and fewer exposed OS instances means fewer vectors for both malware and for the tooling meant to stop it.

10. Why does cloud architecture matter for security, and what does ours actually look like?

The EDR section above describes what happens when a piece of malware lands on an endpoint, but the more fundamental question is what an attacker can reach if they get past that endpoint in the first place. The answer depends almost entirely on how your infrastructure is architected, and the difference between the traditional model and a modern multi-account cloud architecture is not incremental but a different threat model entirely.

The traditional approach is a flat datacentre protected by a perimeter firewall, with the mental model of a castle: thick walls on the outside and relatively free movement once you are inside. Every server, every database, every application sits on the same flat network, the firewall is the primary defence, and the implicit assumption is that anything inside it is trusted. This model made reasonable sense when the perimeter was a physical building and the threat was someone trying to get in from outside, but that assumption has not held for a long time. Attackers get inside perimeters routinely, through phishing, compromised credentials, supply chain attacks, and a contractor’s laptop that connected to the wrong network, and once they are inside a flat network, lateral movement is the technique that turns a single compromised endpoint into a catastrophic breach: they get a foothold on one machine and then move sideways across the network looking for something more valuable, a database, a payment system, an admin console, with often nothing stopping that movement except access controls on individual systems that are frequently misconfigured, inconsistently applied, or simply not granular enough to matter.

Capitec runs approximately 200 AWS accounts organised into an organisational unit structure with Service Control Policies governing what each account can and cannot do, with around fifty of those accounts being production environments and the rest spanning development, staging, testing, and other SDLC stages. The significance of this is not the number of accounts but what account boundaries actually mean in AWS, because each account is a hard security boundary where a compromised workload cannot directly reach resources in another account without explicit, governed cross-account permissions. There is no lateral movement path that does not have to traverse a policy checkpoint, every hop requires permission that has to be explicitly granted, and those permissions are governed by SCPs set at the organisational level that no individual account administrator can override.

Inter-account traffic that does need to flow routes through a Transit Gateway with explicit routing policies, Network Load Balancers handle ingress at the workload level, and nothing is reachable by default; reachability is the exception rather than the rule, and every exception is a deliberate policy decision rather than an inherited consequence of a flat network topology. In a multi-account architecture with hard account boundaries and SCPs enforced from the organisational level, a compromised workload is contained to its account by default, and the attacker has to break out of that boundary before reaching anything else, which requires defeating explicit policy controls rather than simply moving across a flat network.

The managed services layer reinforces this because workloads running on RDS, EKS, and equivalent managed primitives do not expose an operating system surface, leaving no OS for an attacker to escalate privilege on, no kernel to exploit, and no agent to compromise. The attack surface that exists in a traditional server deployment simply does not exist in a managed service deployment.

The honest qualification is that multi-account architecture creates its own complexity: two hundred accounts means two hundred sets of configurations to keep consistent and two hundred places where a misconfigured SCP or an overly permissive cross-account role could create an unintended path. This is why we built ODIN, our internal developer platform based on Spotify’s Backstage, to orchestrate our entire AWS estate from a single control plane where every cloud asset is provisioned from a reviewed, standardised template. No team gets to invent their own approach to cloud configuration and make their own flavour of security mistake, because the standards are centralised even though consumption is federated across teams, and when we raise the bar on a standard, we raise it everywhere simultaneously rather than waiting for individual teams to apply it at their own pace.

Plain English: the way banks were traditionally built, getting through the front door gives an attacker access to most of the building. The way we are built, getting through the front door gets you into one small room with no handle on the inside, and every other room has its own lock, its own key, and its own alarm. The building was designed from the start on the assumption that someone would eventually get in, and the entire layout was drawn to make sure that when they do, they cannot go anywhere.

11. If something goes wrong, how do I know the evidence is trustworthy?

All Capitec transactions and system logs are either immutable, cryptographically hashed, or both. Immutable means the record cannot be changed after it is written, and cryptographically hashed means any modification to the record, however small, produces a verifiable change in the hash value that exposes the tampering, making our logs tamper-evident from the moment they are created. If a record is ever used in a dispute, the underlying data has a verifiable state that reflects what actually happened, and any interference with that record is detectable.

Tamper-evident logs are only part of the answer, though, because the harder problem is the quality of the determination made from those logs. Human investigators make errors, miss things, and draw conclusions from incomplete pictures, which is why we built an agentic system called Neo specifically to address that problem. Neo performs forensic-level analysis of everything relevant to a disputed transaction or security event, pulling from the client’s device telemetry, OpenSearch logs, over fifty read-replica databases, selfie verification records, and full audit trails, and rather than looking at one signal and drawing a conclusion it looks at every signal simultaneously and constructs a complete picture of what actually happened from the moment a session opened to the moment a transaction cleared.

Plain English: instead of a human investigator working through evidence manually and potentially missing something, Neo reads everything at once and produces a forensic determination that is consistent, complete, and reproducible.

Neo runs on AWS Bedrock using predominantly Anthropic models, and we are using it not to summarise a single log file but to reason across dozens of data sources simultaneously and construct a picture that would take a skilled human investigator hours to assemble manually. That said, AI makes mistakes and we are clear-eyed about that, which is why Neo presents its determination alongside the full body of evidence it used to reach it so that a human investigator can see exactly what Neo saw, follow the reasoning, and agree with it, challenge it, or reach a different conclusion entirely from the same material. The investigator is never asked to take Neo’s word for it: Neo does the reading and shows its working, and the human makes the judgement.

Neo also analyses our codebase on GitHub, checking for security vulnerabilities, code quality issues, performance problems, and scale risks, and proposes fixes, running both on demand and as part of our deployment pipeline so that before code goes into production, Neo has already reviewed it for the kinds of problems that create security exposure. This is not a static analysis tool running a checklist but an agentic system reasoning about what the code does and what could go wrong.

12. How do you find security problems before attackers do?

Most security conversations focus on what happens when something goes wrong, but the more important question is what you do to find problems before anyone exploits them. We run continuous agentic analysis of our Cloudflare APIs looking specifically for CVEs, known vulnerabilities, and exploitable patterns including API chaining attacks, where an attacker calls a sequence of API endpoints in combination to achieve something no single endpoint would allow on its own. Individually each door looks locked, but calling them in the right order opens a path the system was never supposed to allow, and finding those paths requires testing combinations rather than individual endpoints, which is exactly what our agentic analysis does continuously without waiting for a human to think to check.

Neo sits at the centre of this proactive posture, because beyond its forensic role in disputes it analyses our codebase for cyber vulnerabilities, code quality issues, performance problems, and scale risks and proposes fixes, running both on demand and continuously as part of our deployment pipeline. Before code reaches production, Neo has already reviewed it for the kinds of weaknesses that create security exposure down the line, reasoning about what the code does, what could go wrong, and what a fix should look like rather than running a static checklist.

The underlying principle is that security cannot be a reactive discipline. By the time you are responding to an exploit, the damage is already in progress, and the only way to stay ahead of a sophisticated, automated threat is to find your own weaknesses faster than an attacker does, at a scale and speed that no human team can sustain manually.

13. What are we not happy with?

Answering the questions above honestly means I also have to answer this one honestly. There are areas where we know our clients deserve better than what we are currently delivering, and I would rather name them directly than wait for someone else to.

Debit order abuse is one. The management and visibility into debit orders, combined with the mechanisms for disputing and reversing unauthorised ones, are not good enough. Clients who have money taken without their authorisation should have a fast, clear, and reliable path to get it back and to stop it happening again, and the current experience falls short of that standard. There are challenges in this space I do not want to go into, but we can and will do better.

Card subscription management is another. The relationship between your card and recurring subscriptions is harder to see and control than it should be, because cancelling a subscription at the merchant does not always stop the charge, and understanding which merchants have your card details stored is not straightforward. Clients should have complete visibility and control over what is attached to their card and the ability to revoke it cleanly, and we are not there yet.

The third area is how we show up for clients when something does go wrong. Our detection and intervention architecture is strong, but our human response is not always at the same level. When we are concerned about activity on an account, we should be reaching out to the client proactively rather than waiting for them to call us, and when a fraud case is open, clients should receive meaningful updates on its progress without having to chase us. The experience of going through a fraud event is frightening and disorienting, and the way a bank communicates during that period either compounds that or alleviates it; we compound it more often than we should. We have the technical capability to do better in all three areas, the work is underway, and I will write about it when there is something concrete to show.

A final note

Sabelo Ndebele asked seven detailed, technically grounded questions about banking security in a public LinkedIn post and directed them at me by name. This post is my answer, and the architecture described here is the reason a SIM swap does not give an attacker your account, the reason a fraud line freeze reaches the authorisation layer before the next transaction clears, the reason a compromised workload in one of our AWS accounts cannot move laterally across our estate, and the reason our forensic determination of a disputed transaction is built from dozens of simultaneously evaluated data sources rather than a single log file reviewed by a tired investigator.

I am not claiming this is perfect. Section 13 names three areas where we are not good enough yet and we know it. But the architecture is real, the controls are real, and the honest admissions are real, and that is what I can offer: not reassurance, but transparency about what we have built, what it does, and where the gaps still are. If you have a question this post did not answer, ask it and I will either answer it or tell you honestly why I cannot.

Andrew