How Capitec Secures Your Money: Real Answers to Real Questions

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.

This post is my attempt to answer the most common ones honestly, in plain language, without hiding behind complexity.

1. Why did Capitec get rid of OTPs, and what replaced them?

We moved away from OTP-based authentication years ago. Not because it was inconvenient. Because it is fundamentally unsafe.

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. Criminals social-engineer mobile network operators into transferring your number to a SIM they control. Once they have your number, they have your OTPs. The entire security layer collapses.

We do not use OTPs as a primary authentication mechanism. Instead, enrollment and high-risk actions require a biometric selfie match, verified against the Department of Home Affairs image database using proprietary matching algorithms. This includes full liveness detection, meaning the system is specifically built to distinguish a real person from a photograph, a video replay, or a synthetic image.

Your phone number being compromised gives an attacker nothing useful in our system, because we do not trust phone numbers as proof of identity.

2. What about SIM swap fraud specifically?

SIM swap is one of the most common attack vectors in South African banking and we treat it accordingly. The short version: we do not trust SIMs.

Your SIM is controlled by a mobile network operator. 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.

When you enroll a new device on Capitec, you are not authenticating via SMS. You are authenticating via a live biometric match against a government identity record. A SIM swap gives an attacker your phone number. It does not give them your face, and it does not give them the ability to pass a liveness check.

If any credential is reset, including your PIN, the biometric verification happens only after a multi-hour enforced cooldown period. That gap is not configurable and not bypassable. It 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. If you want maximum friction on your own account, that tool exists. It uses device fingerprinting to ensure that the app cannot be installed easily on an attacker’s device.

3. 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. I am not going to pretend otherwise. 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.

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. It 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. It is 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, but laid out twice in deliberately opposite orientations. That design choice matters: 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. There is no blocking contention between the system looking for fraud and the system processing payments.

What this means in practice: when your payment arrives, we are traversing the network around the destination account in real time. We can see 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.

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.

We also monitor payments to new beneficiaries specifically. The first time you pay an account you have never paid before, that transaction receives elevated scrutiny.

If the app has been recently installed on a device, limits on certain products automatically reduce for a period. A new install on an unfamiliar device is a risk signal and we treat it as one.

Our card systems use risk-based algorithms and can force a 3DS step-up authentication, meaning the transaction is paused and you are asked to verify it directly in our app when the risk profile warrants it. These pauses are deliberate behavioural interventions. Authorised Push Payment fraud relies on panic and urgency. Slowing the process down breaks that dynamic.

At the core banking level, hard limits exist independently of the app. An authenticated session presenting valid credentials cannot simply override them.

Notice account withdrawals require a biometric selfie at the point of withdrawal, not just an authenticated session. The maximum that can be withdrawn digitally from a notice account 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 malware detection capability, which we built in-house, has had zero breaches since it went live earlier this year. The attackers are not giving up, but so far the detection is holding. More on this in question 8.

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

Yes. And the reason matters.

The critical architectural question is not whether we can stop fraud. It is where in the payment pipeline our intervention sits. A transaction moves through an authorisation layer before it settles. 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. It does not travel through a ticketing system. It does not wait for an escalation workflow. 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. 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. When a client contacts the fraud line via the app, Pulse 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. 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. Anyone claiming otherwise is offering reassurance rather than accuracy.

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. They have live access to something. That something is either a compromised system endpoint, an internal actor, or a misconfigured data pipeline. We address all three.

On network architecture: Capitec operates a zero trust network using Zscaler for ZTNA, Zero Trust Network Access. Zero trust means that 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. 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. This is not logging for retrospective review. It is active pattern matching that looks for deviations from normal behaviour in real time. If we detect abuse, we act immediately. 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. A notification service needs to know that a notification should fire. It does not need to know the transaction amount. Systems only get the data they need to do their job, and no more. 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 PAM solution, Privileged Access Management, and are actively migrating to a zero standing privilege architecture. Zero standing privilege means that elevated access to sensitive systems is not a permanent credential any employee carries. It 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.

On the zero trust layer, Zscaler enforces that segregation at the network level, not just at the application level. An employee cannot reach a system they have no business reaching, regardless of what credentials they hold.

A customer-facing consultant can see which consultants have previously viewed a specific account. That is intentional. 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. 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. This prevents man-in-the-middle attacks even on a malicious public WiFi hotspot.

We also use nonces, a number used once, in our transaction flows. 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. This 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 in over four years.

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. 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. An attacker with a foothold on an internal machine is not trying to drain one account. They are trying 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. 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. Detection without automated response means a human has to see the alert, interpret it, and act on it. That takes minutes at best. A sophisticated attacker operating at machine speed can do significant damage in minutes. Our EDR is configured to respond automatically: isolate the endpoint, kill the process, contain the blast radius before a human has even opened the alert. Here is the honest part; automated response does not have context, it has rules and it applies these 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. To our EDR rules, that looked like credential harvesting. The automated response killed our core banking database, which was the “correct” action given what the rules could see. From the outside, the result was an outage rather than a breach. That is the tradeoff: a system aggressive enough to stop a real attack will occasionally stop something legitimate. 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. The goal is not zero false positives, the goal is 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. We have made that call deliberately and we stand behind it.

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. They got bricked by their own security tooling. Eight and a half million Windows devices went down in hours. Hospitals, airlines, banks, and emergency services lost 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: 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. Because the OS is not exposed, there is nothing for an EDR agent to protect (as there is no attack surface). 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. It is a security improvement. The attack surface that EDR exists to protect is reduced, not just covered. Fewer exposed OS instances means fewer vectors for both malware and for the tooling meant to stop it.

Here is the complete section ready to copy and paste into WordPress:

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. It is a different threat model entirely.

The traditional approach is a flat datacentre protected by a perimeter firewall. The mental model is a castle: thick walls on the outside, and once you are inside, relatively free movement. 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.

That assumption has not held for a long time. Attackers get inside perimeters routinely, through phishing, through compromised credentials, through supply chain attacks, through a contractor’s laptop that connected to the wrong network. Once they are inside a flat network, lateral movement is the technique that turns a single compromised endpoint into a catastrophic breach. Plain English: they get a foothold on one machine, and then they move sideways across the network looking for something more valuable, a database, a payment system, an admin console. In a flat network, there is often nothing stopping that movement except whatever access controls sit on individual systems, and those 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, SCPs, governing what each account can and cannot do. Around fifty of those accounts are production environments. The rest span development, staging, testing, and other SDLC stages.

The significance of this is not the number of accounts. It is what account boundaries actually mean in AWS. Each account is a hard security boundary. A compromised workload in one account 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. Plain English: getting into one account does not get you into any other account. 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. Nothing is reachable by default. Reachability is the exception, not the rule, and every exception is a deliberate policy decision rather than an inherited consequence of a flat network topology.

The comparison in security terms looks like this. In a flat datacentre, a single compromised endpoint gives an attacker a position on a network where most other systems are reachable and lateral movement is constrained only by application-level access controls. The blast radius of a breach is bounded by how quickly the security team detects and contains it, and detection in a flat network is hard because normal traffic and attack traffic look similar. In a multi-account architecture with hard account boundaries, Transit Gateway routing policies, and SCPs enforced from the organisational level, a compromised workload is contained to its account by default. The attacker has to break out of that boundary before they can reach anything else, and breaking out requires defeating explicit policy controls rather than simply moving across a flat network.

The managed services layer reinforces this. Workloads running on RDS, EKS, and equivalent managed primitives do not expose an operating system surface. There is no OS for an attacker to escalate privilege on, no kernel to exploit, no agent to compromise. The attack surface that exists in a traditional server deployment simply does not exist in a managed service deployment. Plain English: a significant portion of our infrastructure cannot be attacked the way traditional infrastructure can, because the parts that would normally be attacked are not exposed.

The honest qualification is that multi-account architecture creates its own complexity. Two hundred accounts means two hundred sets of configurations to keep consistent, 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. 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. The standards are centralised even though consumption is federated across teams. Plain English: every account is built the same way, to the same security standard, because the templates that build them are controlled centrally and reviewed continuously.

The security benefit of that centralisation is that when we raise the bar on a standard, we raise it everywhere simultaneously. A security improvement to a template propagates across the estate rather than waiting for individual teams to apply it at their own pace, or not at all.

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. 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. Cryptographically hashed means any modification to the record, however small, produces a verifiable change in the hash value that exposes the tampering. Our logs are 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.

But tamper-evident logs are only part of the answer. The harder problem is the quality of the determination made from those logs. Human investigators make errors. They miss things. They draw conclusions from incomplete pictures. We built an agentic system called Neo specifically to solve that problem.

Neo performs forensic-level analysis of everything relevant to a disputed transaction or security event. It pulls from the client’s device telemetry, OpenSearch logs, over fifty read-replica databases, selfie verification records, and full audit trails. It does not look at one signal and draw 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. We are not using AI to summarise a single log file. We are using it 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. 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. 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. It runs both on demand and as part of our deployment pipeline. Before code goes into production, Neo has already reviewed it for the kinds of problems that create security exposure, and flagged anything that needs attention. This is not a static analysis tool running a checklist. It is 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. 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. An API chaining attack is 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. Finding those paths requires testing combinations, not just individual endpoints, and that 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. Beyond its forensic role in disputes, Neo analyses our codebase for cyber vulnerabilities, code quality issues, performance problems, and scale risks, and proposes fixes. It runs 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. It does not run a static checklist. It reasons about what the code does, what could go wrong, and what a fix should look like.

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. The only way to stay ahead of a sophisticated, automated threat is to find your own weaknesses faster than an attacker does, and to do that 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 that exist for disputing and reversing unauthorised debit orders 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. The current experience falls short of that standard and we know it. There are challenges in this space, that I dont 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. Cancelling a subscription at the merchant does not always stop the charge. 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. 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. 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, not waiting for them to call us. 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.

I am naming these because fixing them matters more than protecting a clean public image. We have the technical capability to do better in all three areas. The work is underway. I will write about it when there is something concrete to show.

A final note

I write about technology because I think transparency builds more durable trust than polished messaging. The questions in this post are real questions from real people who are genuinely worried about the safety of their money. They deserve real answers.

If you have a question I have not addressed here, ask it. I would rather have the conversation in public than leave the space filled with speculation.

Andrew