Custom Banking Software Development: Core APIs, KYC, and Security

Most buyers approach custom banking software the same way: they draft a feature list, benchmark it against a neobank they admire, then ask for a timeline. The timeline is wrong. The feature list is the small part. The hard parts are the core banking engine underneath, the KYC and KYB plumbing that gates every account, and the audit controls that decide whether regulators let the thing go live at all.

A bank CTO or a fintech founder evaluating a build partner does not need another explainer on PCI DSS. The useful question is narrower. Which core do you buy, where do you still write code, which identity vendors do you wire in, and what controls does an auditor want to see before the first real dollar moves? This is a working blueprint for that decision.

Pick a Core Before You Design Anything Else

The core banking platform is the ledger of record. It holds accounts, posts transactions, calculates interest, and emits the events the rest of the stack reacts to. Everything else — mobile app, admin console, risk engine, data warehouse — is downstream of that choice. Change it later and you are rewriting the bank.

Three cloud-native vendors dominate the shortlist for new builds. Mambu is the composable SaaS pick, favored by neobanks and lenders that want product configuration over code; the openbanking tracker catalog lists it with around 260+ clients across neobanks. Thought Machine's Vault Core sits lower in the stack, with Smart Contracts that define each financial product in code, and Tier-1 deployments at Lloyds and Standard Chartered. Finxact, now inside Fiserv, is the one most US regional and commercial banks end up on when they want a cloud-native real-time core with US charter proximity.

The real split is this. Mambu suits teams that want a product live in months and will accept the platform's product abstractions. Thought Machine suits institutions that need ledger-level control and have the engineering capacity to maintain Smart Contracts in production; one independent comparison notes that Thought Machine's implementation costs trend significantly higher because of that depth. Finxact is the pragmatic US bank answer.

Build your own ledger only if you have a reason the vendors cannot satisfy — a novel asset class, extreme throughput, or a regulatory posture that requires custody of the primitives. "Novel asset class" means a new product; it does not mean a checking account with a different UI. A bespoke double-entry ledger in Postgres with event sourcing is a two-year project before it is boring enough to trust, and boring is the goal.

Design the Services Around the Core, Not On Top of It

Even on a managed core, you will write substantial code. The services that typically live outside the core: an onboarding orchestrator, a KYC decisioning layer, a fraud and transaction-monitoring pipeline, a notifications service, a statements and reporting service, and an open banking facade. Each one has its own data store, its own SLA, and its own audit scope.

A workable pattern is a thin API gateway in front of domain services, each owning its data, communicating over an event bus the core publishes to. For teams on .NET, long-running compliance jobs — sanctions rescreening, statement generation, dormancy sweeps — map cleanly onto hosted background workers. On the data layer, Postgres with logical replication for multi-region read replicas handles reporting and analytics without hitting the ledger. If any of those services needs cross-border availability, decide it before you pick a region, not after.

The anti-pattern to avoid is treating the core as a database and writing ledger-shaped logic in your own services. Posting rules, reversal semantics, and accrual calendars belong inside the core. Your services decide who may call it, how customer-facing products behave, and what the user sees.

KYC and KYB Are Buy, Not Build

Nothing about identity verification should be custom. The reference data, the fraud models, and the regulatory relationships behind these vendors took a decade to assemble. The economics are also brutal if you underestimate them. According to Fenergo's global KYC research, 54% of corporate and institutional banks spend $1,500 to $3,000 per client review, and 21% spend more than $3,000. At the institution level, Fenergo's 2025 survey of senior decision-makers found average annual KYC and AML spend of $72.9 million.

Three vendors dominate the US fintech stack, and they do different jobs:

• Persona is a verification engine with a configurable flow builder — document checks, selfie liveness, database and watchlist lookups.
• Socure is a predictive identity and fraud model, strong on US consumer onboarding and synthetic identity detection.
• Alloy is a decisioning layer that routes applicants across providers under one policy; it does not verify identity itself.

The right pattern for most US fintechs is Alloy on top, Persona or Socure (or both) underneath, plus a KYB-specific provider such as Middesk for business entity checks. One comparison frames it well: Alloy orchestrates 200+ third-party data sources rather than making the identity call itself. If you are a single-product fintech with light volume, start direct on Persona and add orchestration when the policy gets busy.

Treat ongoing monitoring as a first-class flow, not an afterthought. Sanctions screening, PEP rescans, and address changes have to produce auditable decisions that outlive the person who approved them.

Security Architecture Follows the Audit, Not the Other Way Around

Banking security architecture is largely the shape of what SOC 2, PCI DSS, FFIEC, and (for European exposure) PSD2 want to see. The useful discipline is to design to the audit from day one, because retrofitting evidence collection is painful and expensive. IBM's 2025 report puts the global average breach cost at $4.44 million, and financial services at $5.56 million per incident, second only to healthcare.

Concrete controls that recur across every real production bank build:

• Network isolation. Private subnets for the core and its databases, a bastion or SSM for admin access, and no direct internet egress from workloads that touch cardholder data.
• Secrets and keys. KMS-backed envelope encryption, per-tenant data keys where you are multi-tenant, and rotation schedules an auditor can read from Terraform.
• PCI DSS v4.0 scope minimization. Push card data to a tokenization provider and keep your own systems out of scope wherever possible. PCI DSS v4.0 added 64 new or updated requirements, 51 of them mandatory from March 31, 2025; the ones that bite hardest are targeted risk analyses, phishing-resistant MFA, and continuous script integrity for payment pages.
• Strong customer authentication. For any EEA exposure, PSD2 SCA requires two-of-three factor authentication with dynamic linking for payment initiation.
• Immutable audit logs. Append-only, time-stamped, replicated to a separate account, retained to the policy your examiner expects (typically five to seven years).
• Change management with evidence. Every production change tied to a ticket, a reviewer, and a deployment artifact.

Penalties for AML, KYC and sanctions failures totaled $3.8 billion in 2025, down from $4.6 billion the prior year. The decline reflects a shift in enforcement geography, not forgiveness.

Open Banking Is Now Part of the Baseline

Even in markets without a mandate, open banking APIs are now how partners, aggregators, and your own mobile app read from the ledger. The UK ecosystem reached 16.5 million consumer connections by December 2025 and processed 24 billion API calls for the year. Juniper Research expects global open banking API calls to rise from 137 billion in 2025 to over 720 billion by 2029. Plan capacity for that curve, not for today's traffic.

The engineering implications are specific. Rate limits per third party, mTLS and signed JWTs on every call, consent lifecycle management with revocation, and sandboxed developer onboarding. A high-throughput open banking facade is a classic case for Go or Rust at the edge; our write-up of Go concurrency patterns covers the shapes that survive real traffic.

A Realistic Delivery Shape

A greenfield deposit product on a cloud-native core, with Alloy-plus-Persona onboarding and a passable mobile app, is a nine-to-twelve-month build before pilot customers. Modernization of a legacy core is longer and uglier; strangler-fig around a mainframe, with COBOL still answering some calls, is the honest pattern, and we have written about COBOL and DB2 integration in that context. Either way, the sequencing matters more than the stack.

Staff accordingly. A build like this needs a product engineer who has shipped on the chosen core, a security engineer who has survived a SOC 2 Type II, a compliance lead who speaks to examiners, and a QA function that treats regulated workflows differently from marketing-site workflows. If any of those seats is empty, fill it before you start coding.

Where a Build Partner Earns Its Fee

Three places. First, the core selection, because walking it back is a year of lost momentum. Second, the identity and fraud orchestration, because the vendor choices change the loss curve more than any model you train. Third, the audit posture, because evidence collected during the build is evidence you do not have to recreate under deadline. Everything else — the mobile shell, the admin console, the statements PDF — is competent engineering, not fate.

Custom banking software is not a feature list. It is a chain of commitments: a ledger you trust, identity you can defend, controls an examiner will accept, and APIs partners can actually use. Buyers who treat it that way ship banks. Buyers who treat it as a bigger version of a SaaS product ship a prototype and then spend a year turning it into one. If this is the decision in front of you, a conversation with a partner who has done it before — our team at DEV.co or someone else — is cheaper than the alternative.