.webp)
Victoria Olajide
Product & Content Marketing at Devcenter.
The most expensive hiring mistake in fintech is hiring someone who can code but has never built inside a regulated financial system. Even though the system is built and looks functional, the bugs show up months later. Then the architecture needs to be rebuilt. By the time you figure it out, the cost is both financial and techncal.
Most technical interview processes are not designed to catch this gap. A backend engineer who scores well on LeetCode and system design can still ship a payments API with no idempotency guarantee, store card data without tokenization, or build a KYC flow that breaks under CBN audit requirements. In a standard SaaS company, that kind of mistake costs you a sprint. In fintech, it can cost you a customer, a regulator, or a partner relationship.
This article is for fintech CTOs who want to close that gap before making a hire. It covers the five skill domains that separate a strong fintech backend engineer from a strong backend engineer who happens to be working in fintech, with specific vetting questions you can use for each.
Why fintech backend is a different hiring bar
Standard backend engineering, building APIs, managing databases, handling queues, is table stakes for this role. What separates a fintech backend engineer is the layer of constraints they work under every day.
Financial precision matters in a way it does not elsewhere. Currency arithmetic cannot use floating-point numbers. A calculation that rounds incorrectly at scale creates reconciliation problems that operations teams spend weeks unwinding. Most engineers never encounter this constraint until they are already deep inside a production system.
Transaction integrity is another issue. Money movement must be idempotent. If a payment request fires twice due to a network retry, the customer should not be charged twice. Designing for this from the start is a fundamentally different skill from writing a clean REST endpoint. Plenty of experienced engineers have simply never had to think about it.
Compliance is built in, not bolted on. Regulatory requirements like PCI DSS and CBN guidelines shape architecture decisions from day one. Where data is stored, how it is encrypted, who has access to it, and what gets logged are all design questions with regulatory answers. Engineers who learn this after joining cost more to onboard than engineers who already think this way.
Audit trail requirements are non-negotiable. Every access to cardholder data and every sensitive transaction must be logged in a tamper-evident way. This is not a monitoring feature. It is a regulatory requirement. Engineers who do not know this will build logging as an afterthought, and you will find out during an audit.
The 5 skill domains to vet
1. Payment architecture and transaction integrity
This is the most domain-specific skill on the list and the hardest to develop without prior fintech experience. Engineers who have only worked on standard product backends rarely think about the edge cases that make or break a payments system.
What you are looking for is experience designing idempotent payment APIs with idempotency keys and exactly-once delivery semantics, double-entry ledger systems, settlement reconciliation logic, and clean handling of failed or partial transaction states. The candidate should be able to walk you through what happens to money when a transaction times out mid-flight, without hesitating.
They should also understand fixed-precision arithmetic. Specifically, why float types are never appropriate for currency and what data types to use instead, whether that is Decimal, BigDecimal, or an integer pence representation. This is the kind of knowledge that cannot be Googled in the moment. Either they know it or they do not.
2. Security engineering and PCI DSS v4.0
PCI DSS v4.0, the current version as of June 2024, is the baseline security standard for any system that processes, stores, or transmits card data. Backend engineers do not need to be compliance lawyers, but they must be able to build systems that meet the requirements that directly affect their code.
Requirement 3 covers stored account data. Primary Account Numbers must be encrypted with AES-256 or replaced with tokens. Engineers should know the difference between encryption and tokenization and when to use each. Requirement 4 covers data in transit. TLS 1.2 is the minimum, with TLS 1.3 preferred. No fallback to weaker protocols. Requirement 6 covers secure development. Vulnerability management, secure code review, threat modelling, and patch tracking must be part of how the team works, not a pre-launch checklist.
Requirement 8 covers authentication. MFA on all system components in scope, strong password policies, and account lockout after failed attempts. Requirement 10 covers audit logging. All access to cardholder data must be logged centrally. Logs must be retained for at least one year, with 90 days immediately accessible.
A strong fintech engineer will reference these requirements naturally, not only when prompted. If you have to explain PCI DSS to someone you are about to hire to build a payments backend, that is a signal worth noting.
3. KYC, AML, and identity systems
Know Your Customer and Anti-Money Laundering systems are core infrastructure now, not optional add-ons. The CBN requires them. NFIU regulations mandate them. Getting them wrong creates both regulatory risk and reputational damage that is very difficult to reverse.
Engineers do not design the compliance policy, but they do build the systems that implement it. That means integrating KYC API providers for document verification, biometric checks, and liveness detection. It means building transaction monitoring pipelines that flag anomalous patterns. It means handling the data residency requirements that come attached to identity records.
They also need a solid grasp of authentication security. OAuth2, JWT handling, secure token storage, refresh token rotation, and MFA implementation are all areas where fintech systems are frequently vulnerable. Identity is both where attacks most commonly happen and where regulators look most carefully during examination.
4. API design, reliability, and financial integrations
A large part of fintech backend work is integration work. Connecting payment gateways, open banking APIs, card issuing platforms, NIBSS rails, and identity verification services that were not designed to work together cleanly. Engineers who have only worked with well-documented internal APIs often find this harder than they expect.
Production fintech APIs need strong reliability design. Circuit breakers for third-party integrations, exponential backoff with jitter for retries, webhook verification and replay protection, and graceful degradation when upstream services go down. These are not nice-to-haves. They are the difference between a product that survives its first high-traffic moment and one that does not.
API versioning and breaking-change management matter too, because fintech APIs are often consumed by mobile apps, partner platforms, and regulated third parties who cannot absorb sudden changes. How a candidate thinks about this tells you a lot about whether they have shipped in a real production environment or mostly worked on internal tools.
5. Compliance mindset: how they think about risk
This is the hardest skill domain to interview for because it does not produce a concrete artefact. It shows up in how engineers make decisions when no one is watching. Do they add the audit log before the feature ships or after? Do they push back when a product request would require storing data that should not be stored? Do they ask what happens to this during an audit when they are in architecture review?
Engineers with a compliance mindset treat regulatory constraints as design inputs, not deployment blockers. They document architectural decisions and their regulatory rationale. They raise concerns about data retention policies before those policies become a problem. They are uncomfortable with shortcuts that feel fine now but create audit risk later.
You cannot train this mindset from zero in a few months. Look for it in how candidates talk about their previous projects. Do they reference compliance requirements naturally, or does it only come up when you ask directly? That difference tells you more than any technical question will.
When hiring for Nigerian fintech specifically, add questions about data residency design and NIBSS integration experience. These are not deal-breakers on their own, but they determine how quickly someone contributes without needing to be walked through the regulatory environment from the beginning.
Red flags to watch for
These patterns do not automatically disqualify a candidate, but each one is worth probing before you make an offer.
- They treat compliance as someone else's job. Engineers who say "the security team handles that" or "that is the product manager's concern" will create technical debt that shows up during audits.
- No experience with audit logging. If they have never thought about centralized logging or log retention policies, they have not worked in a regulated environment regardless of what their CV says.
- They cannot explain idempotency. This is table stakes for payments. An engineer who cannot articulate what happens when a payment request fires twice is not ready to own a payments backend.
- Secrets live in environment variables. In 2026, secrets management means a vault like AWS Secrets Manager or HashiCorp Vault. Not .env files, not hardcoded configs, not environment variables passed around in deployment scripts.
- They have never written or read a postmortem. Fintech engineers need to learn from failures systematically. A candidate who has never contributed to incident review has not worked on a team that takes reliability seriously.
- They confuse encryption with hashing. Conflating these two, or defaulting to MD5 or SHA-1 for password storage, is a clear signal about their security knowledge baseline.
What Gigson's vetting covers
At Gigson, we have placed backend engineers at Series A and growth-stage fintech companies across Africa since 2018. We have seen where generic hiring goes wrong and built our technical assessment specifically around the five domains in this article.
Every backend engineer in the Gigson network goes through a vetting process that covers systems design with financial constraints, including idempotency, ledger design, and transaction state machines. It covers security engineering fundamentals like encryption, access controls, and secrets management. It covers domain knowledge across payment rails, KYC flows, and reconciliation. And it includes a compliance-mindset review through structured scenario questions, not just technical puzzles.
Trove Finance needed a backend engineer who could handle concurrent transaction volume at scale. Not someone who needed to learn what idempotency meant on the job. Because Gigson's pre-vetting covered this, the engineer was contributing to architecture decisions within the first week. Within three months, Trove's transaction infrastructure had been redesigned to handle 10 times the previous volume without a single production incident.
That is what it looks like when you hire for the right bar from the start.
