OUR DISCIPLINES
Fintech Engineering in
South Africa.
Software can be rolled back, but money cannot be. This is how fintech engineering really works in South Africa: payments, banking, lending and the systems that move the money underneath them. The roles, the market, and what it takes to get the hire right, whether you’re building the team or building your own career.
A LOOK AT THE MARKET
The fintech engineering market in South Africa.
THE TITLE
What 'fintech' in a job title actually means.
Nobody trains as a fintech engineer, they’re more likely trained as front and backend engineers, data engineers, mobile developers or analysts, and the fintech part is added to their experience in a role where the mistakes were expensive. So the title tells you where someone has been, but not necessarily what they can do, which makes it one of the least reliable signals in this field.
The question worth asking instead is how close the person has worked to the money itself. There is a real difference between building the product that sits on top of a financial service and building the part that moves, holds or accounts for the funds. A software engineer might have spent three years at a well known fintech business and never touched the ledger (that is not a criticism of them), it is just a very different job. The person who has owned the settlement process, or the reconciliation, or the message that goes to the bank and cannot be sent twice, has been trained by a set of problems the product engineer has never had to meet.
A business sees fintech on a CV and reads it as evidence of exactly the skill set they are missing, but in reality the candidate’s experience sits one layer above it. The gap only shows up later, usually when something needs to be reconciled at month end or explained to an auditor.
If you’re hiring, be specific in the brief about which layer the role owns. If you’re deciding your own next move, be equally specific about which layer you have actually worked in, because overstating it gets found out quickly in this market and understating it costs you and the business money.
THE ROLES
The roles, and what each one involves.
The useful way to read these roles is by what happens if the person gets it wrong. Some of these jobs produce a poor customer experience when they fail. While others produce a financial loss, a regulatory obligation, or a number in a ledger that no longer matches reality. The tooling moves constantly, but the distinction between those two groups does not.
Backend engineer, financial services
Builds the services and APIs a financial product runs on, with the added constraint that the numbers have to be right at every moment, not right once everything catches up. The broadest role here, and the one whose value depends most on how close to the money they have actually worked.
Common tools: Java, Kotlin, C#, Go or Python, event-driven architecture, PostgreSQL, and distributed transaction and idempotency patterns.
Compliance, RegTech engineer
Builds the operational machinery behind onboarding, monitoring and reporting, so that FICA, POPIA and regulatory obligations are handled by systems rather than by people with spreadsheets. Valued most in businesses scaling faster than their manual processes can hold.
Common tools: KYC and onboarding orchestration, identity and verification APIs, audit trail and evidence tooling, regulatory reporting pipelines, and workflow automation.
Core banking engineer
Works on the systems of record that hold accounts, balances and the ledger itself. Often a mix of modern platform work and deeply established systems that cannot be casually changed. A specialist role, and one where migration experience is worth a great deal.
Common tools: core banking platforms such as Thought Machine, Mambu or Temenos alongside in-house cores, double-entry ledger design, batch and end-of-day processing, Java, and SQL.
Credit & decisioning engineer, risk analytics
Turns credit policy into code, and keeps the decisioning working as policy, data and regulation change. A role that lives at the point where the National Credit Act meets a production system, and where a quiet error compounds across thousands of decisions before anyone notices.
Common tools: decision engines and scorecard deployment, bureau integrations, affordability and NCA-aligned logic, Python or Scala, and SQL.
Data engineer, financial services
Builds the pipelines behind reporting, risk models and regulatory submissions, where the standard is not just clean data but data with a defensible lineage. Increasingly the foundation for both the models and the audit.
Common tools: Kafka, Spark and dbt, cloud warehouse platforms, lineage and data quality tooling, and SQL with Python.
Fraud and financial crime engineer
Builds the systems that decide, in the time it takes a transaction to clear, whether it should. Sits between engineering and financial crime teams, and is judged on two numbers that pull against each other: what gets through and what gets wrongly stopped.
Common tools: rules engines and real-time scoring, transaction monitoring and sanctions screening platforms, feature pipelines for ML models, and Python.
Integrations engineer
Connects the business to banks, schemes, bureaus and partners, which in practice means designing for systems you do not control and cannot fix. The role that absorbs the most operational reality, and the one where patience and rigour matter as much as technical depth.
Common tools: REST and webhook API design, host-to-host and file-based bank integrations, Kafka or RabbitMQ, retry and idempotency patterns, and sFTP with legacy file formats.
Mobile engineer, banking & wallet apps
Builds the app that is, for most South African customers, the entire relationship with the institution. Carries a security burden most mobile work does not: device binding, biometric authentication, secure storage and the app store release cycle in a regulated environment.
Common tools: Swift, Kotlin, React Native or Flutter, biometric and device-binding APIs, secure storage, and app attestation.
Payments engineer
Builds and runs the systems that move money between parties, and owns the unglamorous parts that decide whether it works: idempotency, retries, settlement and reconciliation. The role where correctness matters more than elegance, and where experience of real failure modes is the whole value.
Common tools: ISO 20022 and ISO 8583 messaging, card scheme and switch integrations, real-time payment rails, event-driven architecture, and Java, Kotlin or Go.
Payments product manager
Owns the commercial and technical shape of a payments or lending product, including the parts most product roles never touch: scheme and partner-bank rules, pricing and interchange, and what the business is allowed to do. Technical enough to hold the roadmap with engineering, commercial enough to defend it upstairs.
Common tools: scheme and partner-bank rules, pricing and interchange models, product analytics, API product design, and regulatory requirements mapping.
Security engineer, payments & cards
Owns the parts of security that are specific to handling money and card data: key management, tokenisation, cryptographic operations and the controls an assessor will actually test. Distinct from general application security, and priced accordingly.
Common tools: PCI DSS, HSMs and key management, tokenisation and encryption, threat modelling, and secure SDLC practices.
Other disciplines we recruit in
Software engineering · DevOps and cloud engineering · Project and programme management and more
IF YOU'RE HIRING
Hiring for systems where the errors are financial.
When it comes to most engineering hires you’re assessing whether someone can build the ‘thing’. Here you are assessing something narrower and harder to see, which is how carefully they think when being wrong has a cost attached. Those are not the same trait, and the second one does not show up in a technical assessment, because assessments are built around getting to a working answer rather than around what you do when the answer might be irreversibly wrong.
A great place to start is with the domain question. Financial services domain knowledge is learnable, and some of the best engineers in this market arrived from outside it. What is not quickly learnable is the instinct that comes from having been responsible for money in production. The habit of asking what happens if this runs twice, designing for the reconciliation before the happy path, assuming any external system will eventually return something that makes no sense. If nobody in the team has that instinct already, the hire needs to bring it. If two or three people do, you can hire a strong engineer from another domain and let them learn the regulation, which is usually the cheaper route.
The interview that works best is one built around failure rather than knowledge. Ask about a payment that went out twice. A reconciliation that did not balance and what the process was for finding out why. A time the fraud rules were tightened and good customers got caught in it. An integration partner who changed something without telling anyone. The key here is to listen for whether they talk about the customer and the money, or only about the code. Did they know what the exposure was, in rands, while it was happening? You will learn a lot from this process.
Then listen for the thing that is easy to miss. In this field the strongest people tend to be slightly pedantic, slow to agree that something is definitely fine, and comfortable saying they would rather hold a release than ship something they cannot explain. In a normal product team that reads as friction, but in a business where an error becomes a regulatory conversation, it is precisely the temperament you are hiring for.
WHY LEVELS MATTER
Understanding seniority.
Here is a top line view of what each level looks like in practice, whether you are writing a brief or working out where you sit.
-
A junior professional delivers well-defined work inside a system someone else designed: an endpoint, a report, a fix, a piece of a decisioning rule. In this field the thing to hire for is carefulness rather than speed. The good ones read the existing code before changing it, ask what a field actually means before assuming, and are visibly uncomfortable when something does not add up. That discomfort is the trait that grows into everything else.
-
A mid-level professional owns a defined area end to end, whether that is an integration, a service, a set of decisioning rules or a reporting pipeline. They understand not just how their part works but what it is accountable for, and they can be trusted to spot when a change has consequences somewhere else in the flow. Usually the level at which someone starts fielding the operational questions when a transaction looks wrong.
-
A senior professional designs the approach and is trusted with the parts where correctness is not negotiable: the ledger, settlement, the money-movement path. Seniors here are measured by the failure modes they anticipated and designed around, and by whether they can explain a system clearly to a risk, finance or compliance audience without either dumbing it down or hiding behind it.
-
A lead or principal professional sets the technical direction and carries the judgement calls where engineering, risk and commercial pressure disagree. At this level the work is deciding what the business can safely commit to, what a regulatory change actually requires in the code, and which of the compromises made three years ago now has to be paid off.
Skills that will command a premium.
The premium in fintech engineering follows accountability rather than technology. Building a service that talks to a payment provider is ordinary work, and the market prices it that way. Owning the ledger, the settlement process, the decisioning logic or the card data environment is a much smaller field, because the number of people who have genuinely held that responsibility is small and every business that has one is trying to keep them.
Specific things that move the number: real core banking migration experience, which almost nobody has and everybody eventually needs; card and PCI depth, particularly key management and tokenisation, where getting it wrong has a defined and unpleasant consequence; real-time payments experience, where the absence of a settlement window changes the engineering problem entirely; and fraud and financial crime work where someone has tuned a live system rather than just built one.
Underneath the specialisms, the fundamentals still carry: precise data modelling, a real understanding of consistency and idempotency, and enough SQL to interrogate what actually happened rather than what the logs claim. And the combination that is worth more than the parts is the engineer who can sit in a regulatory or audit conversation, understand what is being asked, and translate it into a design without needing a compliance officer to interpret both directions. That person is rare, hard to replace and fully aware of both facts.
Understanding the finteh salary package
Financial services in South Africa pays differently from the rest of tech, so comparing base salaries alone will mislead you in both directions.
The established institutions put real weight into the structured parts: retirement and medical contributions that are genuinely valuable rather than nominal, formal bonus schemes, and a level of employment stability that matters more to some people than they will admit in an interview. The newer businesses compete with equity, scope and pace, which can be worth far more or nothing at all, and candidates are increasingly sharp about asking which.
There are also things specific to this world that shape a decision. Vetting and clearance can add weeks to a start date, so a candidate weighing two offers may effectively be weighing two timelines. Restraint of trade clauses are common and taken seriously here, and they can narrow someone’s next move in ways worth understanding early rather than at offer stage. On-call matters where payment rails are involved, because the failure window is not an ordinary business hours problem.
Then there is the part that determines the next five years rather than the next one: whether the person gets to work on the money-critical systems or around them. That access is the single most valuable thing on offer in this discipline, it costs nothing to give the right person, and it is the reason good engineers leave better-paying jobs.
THE COST
Contract vs Permanent.
The contract decision in financial services carries a question most disciplines do not have to answer, which is what the contractor is allowed to touch. Access to card data, customer records and production money movement sits inside a regulated control environment, and bringing someone in means vetting, defined access, and an audit trail that holds up later. That is workable and routine, but it is a real cost in time and it belongs in the decision rather than being discovered halfway through onboarding.
Set against that, a lot of the most valuable work in this field has exactly the shape contract was designed for. A core migration, a new rail integration, a PCI remediation programme, a decisioning platform replacement: defined scope, a real end date, and a depth of specialist experience no business can justify carrying permanently. Paying a day rate for someone who has done that specific migration three times is usually far cheaper than a permanent hire learning it once on your system.
The line we would draw is about accountability rather than cost. Work that ends can be contracted. Ownership that has to persist, the ledger, the decisioning policy, the security of the card environment, needs someone who will still be there when the consequences arrive. Where businesses get caught out is contracting the ownership rather than the work, and finding that the only person who understood the settlement logic invoiced their last month in March.
For the engineer, contract in this discipline is a genuinely strong route, because migration and integration specialists are scarce and priced accordingly. What you give up is depth of institutional context and the slow-built trust that eventually gets you handed the systems that matter most. That is a real trade, and worth making deliberately rather than by default.
Where Acuity places contractors, the compliance administration sits with us: PAYE and SARS handled, contracting structures that stand up to scrutiny, and documentation your own audit process can look at without flinching. For contractors you have sourced yourself, we can run the payroll side alone, with no recruitment engagement attached.
Fintech salaries in
South Africa.
FOR CONTRACTOR ROLES
Seniority
Indicative hourly rate
> Junior engineer
R450 – R650
> Mid-level engineer
R650 – R800
> Senior engineer
R850 – R1200
> Lead or Principal engineer
R1200 – R1500
FOR PERMANENT ROLES
Seniority
Annual cost to company
> Junior engineer
R650K – R800K
> Mid-level engineer
R850K – R1.1M
> Senior engineer
R1.2M – R1.6M
> Lead or Principal engineer
R1.6M – R2M
Figures are drawn from Acuity’s own placements across the South African market and are indicative ranges, not quotes. Actual pay and rates vary with specific skills, sector, location and how in-demand a role is at the time. Contractor rates are excluding VAT. Last reviewed: September 2026
IF YOU'RE BUILDING A CAREER
Making your next move into fintech a good one.
The thing that compounds in this discipline is proximity. Two engineers can spend the same three years at the same fintech and leave with completely different market value, because one of them worked on the ledger and the other worked on everything around it. Nobody tells you this at the time. You find out when you interview somewhere serious and the questions go one layer deeper than you can follow.
So the useful question about a role is not what the company does, it is what you will personally be accountable for. Ask which systems you would own, whether you would be in the room when a design decision about money gets made, and what happens when something goes wrong at two in the morning. A smaller business where you own the settlement path will do more for you than a larger one where you build features on top of someone else’s core.
It also pays to get comfortable with the regulatory side rather than treating it as somebody else’s department. Engineers who can read a requirement, understand what it actually obliges the business to do, and design for it without needing everything translated are a small group, and they end up in the roles with the most leverage. It is not difficult material. It is just unfashionable, which is exactly why so few people bother.
And here’s how we work with you. We take the time to understand where you’re trying to get to, not just what’s already on your CV, and we only put you forward for roles that move you that way. You stay in control the whole way through, and we’d rather point you at the right role than hurry you into the nearest one.
COMMON QUESTIONS
Fintech questions, answered.
FOR BUSINESSES LOOKING TO LEAD, BUILD & SCALE
Do we need someone with financial services experience, or can a strong engineer learn it?
It really does depends on the current make up of your current team. Domain knowledge and regulation can be learned by a good engineer in months. The instinct for designing systems where errors are financial takes longer, and it is learned by being responsible for it. If nobody in the team has that instinct yet, buy it. If two or three people do, hire on engineering strength and let the domain follow.
We're modernising our core. Should that be a permanent team or contractors?
Usually both, split along a clear line. The migration itself has an end date and needs people who have done it before, which is contract work by nature. What has to stay permanent is the ownership of the system afterwards, because the decisions made during a migration echo for years and someone needs to be there to answer for them.
Why do payments roles take so long to fill?
The pool of people who have genuinely run money in production is small and mostly employed, and because the specification often asks for more than the role really needs. We would usually start by separating the parts of the role that require payments-specific experience from the parts that require strong engineering, since those are two different searches with very different timelines.
How do we assess someone technically when the risk is regulatory rather than functional?
Shift the assessment from building to reasoning. Start by giving them a realistic failure scenario, a duplicate payment, a reconciliation that does not balance, a partner system returning something impossible, and ask how they would find out what is true and what they would do next. It tells you more in twenty minutes than a coding exercise does in three hours.
FOR PROFESSIONALS EXPLORING
I'm a backend engineer outside financial services. Can I move into fintech?
Regularly, yes. What helps most is being able to show you have thought about correctness, consistency and failure rather than just delivery. Being straightforward about what you have not done matters too, because in this market overstating it is noticed quickly.
Is a specialism worth more than staying broad?
In this discipline, usually yes. Depth in payments, core banking, financial crime or card security is scarce and priced accordingly. The risk is picking a specialism that is a single platform rather than a durable problem, so go deep on the problem and stay curious about the tooling.
How much do I need to know about regulation
More than most engineers do, and less than you fear. Understanding what FICA, POPIA, the NCA and PCI actually require of a system, rather than just recognising the acronyms, puts you ahead of most of the field and opens the roles with real ownership.
Do you place contract and permanent roles, and can you help with remote work?
Both, and yes. Fintech contract work in South Africa is strong at the specialist end, and a growing number of roles are hybrid or remote, though regulated environments vary in what they will allow. Worth a conversation about what you actually want before you start applying.