Banking and financial services software, built the way the sector actually works.
Payments, lending, brokerage and digital banking platforms - engineered against PCI-DSS, KYC and AML obligations from week one, not retrofitted before audit. Five financial platforms already in production, and a custom engineering team for everything beyond them.
Custom build - 2 to 8 weeks, scoped
Ready-made platform - 6 working days
Six working days is the launch timeline for a ready-made platform as it ships - branded, deployed and live on infrastructure you own. Sector work beyond that, and the custom track above, is scoped and quoted in writing before anything starts. Both tracks are the same engineering team. Every figure on this page is defined on our facts page.
Financial platforms deployed on Miracuves
- UbanLC
- Talokitoko
- MyQif
- Ryke
- ShopRaja
- GUS
What a payments build actually contains
The sequence below is where financial platforms are won or lost. Every phase names what it requires and, where one exists, the shipped platform that removes it.
It is worth being clear about what the sequence is not. It is not a methodology we sell, and it is not the same order every consultancy prints. It is the order the dependencies actually impose: you cannot design a ledger before you know your licence position, you cannot certify with an acquirer before the integration exists, and you cannot cut over before both ledgers agree. Programmes that slip in this sector almost never slip on the build. They slip because provider approval started in month three, or because a control was retrofitted after an assessment found it missing.
Three of the seven phases have no shortcut, and we mark them as such below rather than implying the whole arc compresses. What a shipped platform removes is the middle: the ledger, the onboarding stack and the payment layer, which is where most of the build time and nearly all of the subtle correctness problems live. Scoping, certification and cutover take the time they take whichever track you are on.
Regulatory scoping before architecture
Which licence you hold or rent decides the build. An EMI licence, a sponsor bank arrangement and a full banking licence produce three different ledgers, three different reconciliation obligations and three different answers to who holds client money. Settling that first is not bureaucracy, it is the constraint every later decision inherits.
We also decide here what you are deliberately not doing. Operating in four markets at launch sounds ambitious and usually means four regulators, four payment providers and four verification standards before you have a single paying customer. Most platforms that reach production on schedule launched in one market and expanded from a working base.
The output is a written scope: card-data flow, PCI boundary, data residency, client-money handling, and the list of provider contracts to start negotiating this week rather than in month three.
Ledger architecture and reconciliation model
Double-entry from the first commit. Balances are derived from an immutable entry log rather than stored and adjusted, because a stored balance that drifts is discovered by a customer, not by you. Reconciliation against provider settlement files is designed now, not bolted on.
Idempotency is settled in the same week. Every provider will retry a webhook it believes you missed, and a platform that treats the retry as a fresh event books the money twice. An idempotency key on every write makes the retry harmless, and it has to exist before the first integration rather than after the first incident.
Multi-currency decisions land here too. Holding balances in several currencies means deciding where FX is realized, how rounding is handled and which side of the trade carries the spread. Retrofitting currency into a single-currency ledger is close to a rewrite, so it is cheaper to build for it even when launch is domestic.
A production double-entry ledger with transaction history, reconciliation and multi-currency wallets.
Onboarding, KYC and AML screening
Identity verification, document capture, liveness, sanctions and PEP screening, and the case-management queue a compliance officer actually works in. Vendors differ by market, so the integration sits behind an interface rather than through the codebase.
Tiering is a commercial decision wearing compliance clothing. Every field you add at signup costs conversion, and every one you remove pushes work into the review queue. A wallet can open on a phone number and ask for documents when volume crosses a threshold you set; a brokerage cannot, because identity is required before the first trade. The same codebase supports both, and the difference is configuration.
Screening produces false positives, constantly, and that is the design constraint nobody plans for. A common surname against a sanctions list generates a hit that a person has to clear, so the review screen has to be genuinely fast to work: screening result, documents and account history on one page, with the disposition and its reason captured in one action.
Tiered KYC with document capture, review queues and approve-reject dispositions, plus an AML posture documented per deployment.
Payment rails and provider redundancy
Card acquiring, local rails, payouts and FX. Single-provider deployments fail on the day that provider does, so routing, retry and failover are built in rather than promised. Webhook signature verification and replay protection are non-negotiable.
Local rails are usually where a market is won. Cards are universal and expensive; UPI in India, PIX in Brazil, SEPA instant across Europe and mobile money across much of Africa are cheaper, faster and what customers expect. A platform that only speaks card will lose on price to one that does not.
Payouts deserve their own attention because they fail differently from collections. A batch can partially succeed, leaving some beneficiaries paid and others not, and the platform has to know precisely which without guessing. Batch state, per-item status and a safe retry path are built here rather than discovered during the first failed run.
Multi-gateway payment layers with wallet funding, payouts and reconciliation already wired.
Risk, fraud and dispute handling
Velocity rules, device fingerprinting, manual review, chargeback representment. The operational side matters more than the model: someone has to work a queue at nine on a Monday, and that screen is part of the build.
Rules before models, deliberately. A rule engine your risk team can change without a release will outperform a machine-learning model nobody can explain for the first year, because you have no traffic to train on and every decline needs a reason you can give a customer. Models come later, tuned against your own data rather than shipped pre-trained on someone else's.
Chargebacks are a workflow, not an event. Evidence has to be assembled to the scheme's format inside a deadline, and platforms that leave representment as a manual email exercise lose disputes they should win. The evidence a case needs is captured at transaction time, which is a decision made here rather than when the first dispute lands.
Penetration testing and acquirer certification
External VAPT, remediation, and the certification your acquirer requires before production traffic. Every platform we ship carries a VAPT and compliance document mapping the OWASP Top 10, so the assessment starts from a known posture rather than a blank one.
Acquirer certification is the item most likely to move your launch date, and it is the one you control least. The acquirer tests your integration against their sandbox on their timetable, and a rejected submission can cost weeks waiting for a retest slot. Booking that slot early, before the code is finished, is worth more than any amount of internal urgency later.
Remediation is scoped honestly. A penetration test on a financial platform will find things, and the useful question is which findings block production and which are tracked and fixed after. We take a position on that in writing rather than presenting an undifferentiated list, because a team treating every low-severity finding as a launch blocker will not launch.
Shipped platforms arrive with a security handbook and VAPT report. The test still happens; it starts from a documented baseline.
Cutover with parallel-run reconciliation
Production traffic moves while the previous system keeps running, and both ledgers are reconciled daily until they agree without exception. Migrating balances without a parallel run is how platforms lose money quietly for a fortnight.
Balance migration is the moment of maximum risk in the whole programme. Balances are frozen, exported, imported as opening entries with their own audit reference, and verified against the source total before anything is unfrozen. Any mismatch stops the cutover; there is no acceptable rounding difference when the number is somebody's money.
The rollback plan is written before it is needed and is tested rather than assumed. It has a decision owner, a time limit and a defined state to return to. Cutovers that go wrong go wrong at two in the morning, and that is not when anybody should be deciding what the rollback is.
Want any of these phases costed against your own scope and licence position?
Book a technical callWhere the money actually goes
Every financial platform is this diagram with different names on the boxes. The hops are easy. What separates a platform that survives audit from one that does not is what happens when a hop fails, and whether the ledger still balances afterwards.
Idempotency keys are what stop the first failure mode becoming the third. A payment provider will retry a webhook it thinks you missed, and a platform that treats the retry as a second event books the money twice. The customer finds it before you do.
Why the ledger stores entries and not balances
A stored balance is a cached value, and every cached value eventually disagrees with its source. When it does, you cannot tell whether the balance is wrong or the history is, because there is no separate record to check against. Deriving the balance from an immutable entry log means the two can never disagree by construction, and a discrepancy against the provider's settlement file becomes a specific, findable entry rather than a number that is simply off by forty pounds.
The cost is computation, and it is the cheapest insurance in the sector. Balances are materialized into a read model and rebuilt from the log on demand, so the query is fast and the truth is still the log. Every platform we ship in this space works this way, and every custom financial build we take on starts here whether or not the client asked for it.
Want the ledger and reconciliation model walked through against your own volumes?
Talk to an engineerEight operators, eight different builds
"Fintech" is not one buyer. The ledger, the regulator and the failure mode change completely between them.
Digital banks and neobanks
Current accounts, cards, multi-currency wallets and sponsor-bank integration. The hard part is rarely the app. It is holding a ledger that reconciles against the sponsor's own records every single day, and proving it to whoever asks.
3 shipped platforms
Payment processors
Acquiring, routing, settlement and merchant onboarding. Merchant risk is the business you are actually in, and the reconciliation nobody looks at is the one that decides whether you are solvent at month end.
Custom build
Remittance and FX
Corridor pricing, jurisdiction-specific compliance and payout partners. A quoted rate has to hold until settlement, which means the exposure between quote and payout is yours and has to be modelled, not hoped over.
2 shipped platforms
Brokerages and trading
Order routing, market data, portfolio accounting and margin. Identity is required before the first trade, so onboarding cannot be tiered the way a wallet can. The client portal is an inspected surface.
2 shipped platforms
Lending and BNPL
Origination, underwriting, servicing and collections. Every decline needs a reason you can defend, every affordability check needs its inputs retained, and the servicing side runs for years after the loan is written.
Custom build
Crypto exchanges
Custody, matching and key management, where the failure mode is theft rather than downtime. Twelve shipped platforms and eight dedicated practices sit behind this on our digital assets page.
See digital assets
Wealth and investment
Goal-based portfolios, rebalancing, statements and fee accrual. Suitability records have to survive years of scrutiny, and fee calculation errors compound quietly across an entire book.
Custom build
Insurance and InsurTech
Quote and bind, policy administration and claims workflow. Policy versioning is the unglamorous constraint: a claim is assessed against the wording in force on the date of loss, not today's.
Custom build
Five of the eight can start from something already running. Three are custom builds because nothing off the shelf carries the domain properly, and we would rather say that than sell you an adaptation that fights you for two years.
Not sure which of these you are, or you sit across two of them?
Book a scoping callHow the work actually runs
Six stages, the same on both tracks. What changes between a custom build and a platform adaptation is how long stage three takes, not whether the other five happen.
Scoping against what exists
We start from your licence position, your existing systems and the markets you are entering, because those three decide the architecture before any preference does. If you hold an EMI licence in one market and use a sponsor bank in another, that is two ledger topologies, and finding out in month four is expensive. This stage ends with a written scope covering card-data flow, PCI boundary, data residency and which provider contracts you need to start negotiating immediately.
Architecture and control mapping
Every regulatory control gets mapped to a place in the system that satisfies it, before the system is built. Segregation of duties becomes a role model. Evidence retention becomes a schema. Transaction monitoring thresholds become configuration rather than deployed code, so a compliance officer can change one without a release. Controls retrofitted after a build are always more expensive and usually weaker.
Build against production-shaped data
Financial platforms fail on volume and edge cases, not on the happy path, so test environments carry realistic data shapes from the start: partial settlements, reversed transactions, duplicate webhooks, failed payouts, currency rounding. A platform that has only ever seen clean data will meet dirty data on the day it handles real money.
Length varies by trackCompliance and security validation
Internal review against the mapped controls, then external penetration testing, then remediation. Our platforms arrive with a VAPT and compliance document mapping the OWASP Top 10, so the external test starts from a documented baseline rather than a blank page, and the remediation list is shorter for it.
Certification and provider sign-off
Acquirer sandbox certification, payout provider approval and any regulatory notification your licence requires. This stage depends on third parties and is the most common cause of a date slipping, which is why we start the paperwork in stage one rather than here.
Cutover and day two
Parallel run with daily reconciliation until both ledgers agree without exception, then traffic moves, then we stay on for the first month because that is when the edge cases arrive. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.
Want this sequence mapped against your licence position and target markets?
Book a technical callFive financial platforms already in production
Every one ships with full source-code ownership, deployed on your infrastructure under your brand. Adapt one, or use it as the reference architecture for a custom build.
They fall into two groups, and which one you start from matters more than which name you recognise. Banking and transfer platforms carry the ledger, multi-currency wallets and transfer rails, and are the usual starting point for neobanks and remittance operators. Trading and brokerage platforms add order handling, portfolio accounting and the client portal, with identity verification required before the first trade rather than tiered. If you are building an exchange, a wallet or anything holding digital assets, that work sits on our digital assets page instead, with twelve shipped platforms and eight dedicated practices behind it.
Starting from one is not a commitment to keeping it. A shipped platform can also serve as the reference architecture for a custom build - you take the ledger and reconciliation model and replace everything above it. That is a legitimate route, and usually a cheaper one to a bespoke platform than starting from an empty repository, because the part that is hardest to get right is already correct and already documented.
Where the PCI boundary falls
Scope is the whole game. Every system that touches, stores or can influence card data is inside your assessment, and every one you keep outside is an assessment you do not have to pay for annually. This is the single architectural decision with the largest recurring cost attached.
What this sector requires
PCI-DSS
Card data never touches your servers unless it has to. Tokenization at the boundary, scope kept deliberately small, and the SAQ level agreed before architecture is fixed. The distinction that matters: a platform cannot be compliant on your behalf, because compliance attaches to your organization and your scope. What a platform can do is keep that scope small enough that the annual assessment stays cheap, and document the data flow so your assessor is not reverse-engineering it.
KYC and AML
Tiered verification, sanctions and PEP screening, transaction monitoring thresholds and a suspicious-activity workflow, with evidence retained in a form a regulator can actually read. Vendor coverage varies by market, so the integration sits behind an interface and swapping providers in one country does not disturb another. Thresholds live in configuration because they change on a compliance officer's judgment, not a release cycle.
Ledger integrity
Immutable entries, derived balances, idempotent writes and daily reconciliation against provider settlement files. Discrepancies surface as alerts to a named owner rather than as customer support tickets three weeks later. This is the control that makes every other financial control auditable, because without a trustworthy ledger there is nothing to audit against.
Data residency
Regional deployment where the regulator requires it, with the data-processing boundary documented rather than assumed. Residency is rarely a single decision: personal data, transaction data and backups can each fall under different rules, and a platform that treats them as one thing will be non-compliant in at least one of them.
Auditability
Who changed what, when, and on whose authority, across payouts, limits, KYC dispositions, refunds and configuration. Attributable to a named account and retained by policy. Shared administrator logins destroy this, which is why role scoping is built in rather than offered as an option: a support agent cannot reach payouts and a reviewer cannot approve their own case.
Provider redundancy
More than one acquirer or payout partner, with routing and failover tested before you need them. Single-provider platforms have a single point of revenue failure, and provider outages are not rare events. The cost of a second integration is a fortnight; the cost of not having one is every transaction during an outage plus the customers who do not come back.
Want to open any of these platforms and look inside before deciding?
See the live demosOnboarding is where good platforms lose people
Verification is not one gate, it is a graded series of them, and the grading is a commercial decision as much as a compliance one. Ask for too much at signup and conversion collapses. Ask for too little and the review queue becomes a second business.
The tiering matters commercially. A remittance operator moving small amounts can open a tier-one account on a phone number and a device fingerprint, then ask for documents only when cumulative volume crosses a threshold you set. A brokerage cannot, because the regulator requires identity before the first trade. Same codebase, entirely different onboarding, and the difference is configuration rather than a rebuild.
The review queue is the part most vendors skip and every operator ends up needing. Somebody has to look at a flagged applicant and decide, with the screening result, the documents and the account history on one screen, and their decision has to be attributable afterwards. We build that screen because a compliance function without it runs on email and spreadsheets, which is exactly what an examiner will find.
Want your tiering modelled against conversion and expected review load?
Talk to an engineerBuilt custom when nothing off the shelf fits
The same team, working from zero. These are the disciplines a financial platform draws on most, and the layers they sit in.
Providers sit behind interfaces on purpose. Acquirers get replaced, KYC vendors lose coverage in a market, and sanctions feeds change format. A platform that threads a provider's SDK through its core has to be rewritten when that happens; one that does not treats it as a fortnight of integration work.
Payment gateway engineering
Acquirer integration, routing, settlement, webhook verification and payout batching.
Payment gateway developmentCore platform
Ledger design, idempotent services and event-driven reconciliation at transaction volume.
Microservices developmentExchange and custody
Matching engines, wallet infrastructure and hot-cold separation for digital assets.
Crypto exchange developmentBlockchain and contracts
Smart contracts, DeFi protocols and on-chain settlement where the product calls for it.
Smart contract developmentRisk and analytics
Transaction monitoring, fraud signals and the reporting a compliance team runs on.
Data analyticsSecurity engineering
Threat modelling, penetration testing, remediation and audit-ready documentation.
Hire cybersecurity engineersNeed something this list does not cover?
Ask about custom workWhat we built, and what it delivered
Named deployments with outcomes their operators agreed we could publish. Where a client is under NDA we say so rather than inventing a logo.
Cross-border neobank
APAC corridor bank
Multi-currency accounts and cards against a fixed regulatory go-live date. Core banking, compliance and mobile all had to be ready for the same week, with no room to move the deadline.
Made the regulator window
Peter Lu, founder. "We had a hard window - regulator go-live in mid-December."
Remittance
Talokitoko
A cross-border corridor for the African diaspora in Europe. Compliance, FX and the payout pipeline are the hardest part of a remittance build, and all three had to work before a single transfer could settle.
Live within six weeks
Charles Eveillard, founder.
Exchange
Offshore trading venue
A matching engine, custody and mobile apps under an exchange licence that had sat unused for close to a year, after every quote from a US development shop came back at six figures.
Live inside a month
Anton Barbaro, founder.
Named clients, in their own words, from our published testimonials. Where a client is under NDA we say so rather than inventing a logo, and we do not publish a metric we cannot source.
Want to speak to a reference operating in your sector?
Request a referenceWritten on this sector
The reading a financial buyer does before they contact anyone.
PCI-DSS scope: what actually falls inside it
ArchitectureWhy your ledger should never store a balance
PaymentsRunning two acquirers before you need the second one
CostWhat a digital banking platform costs in 2026
Want these as a briefing pack for your board or engineering team?
Request the pack“Every US quote came back at six figures and nine months.”
Chadi El BoustaniFounder. Centralized exchange with KYC, wallets and mobile apps, delivered ahead of a token launch.
That gap is the whole reason this page exists. A financial platform built from an empty repository genuinely does cost six figures and take the better part of a year, because the ledger, the onboarding stack and the payment layer each take months to get right and all three have to be correct before you can take a single live transaction.
We publish forty client testimonials with names and companies, and we state plainly what each platform does not do before you buy rather than after. Ten of the forty are financial platforms.
Questions financial buyers actually ask
Twelve of the questions that come up on a first call, answered the way we answer them on the call. Where the honest answer is that something is not included, it says so.
Are your platforms PCI-DSS compliant?
A platform cannot be compliant on your behalf - compliance attaches to your organization and your scope. What we do is keep that scope small: tokenize at the boundary so card data never lands in your database, document the data flow, and build against the SAQ level you are targeting. The assessment is yours; the architecture that makes it survivable is ours.
Can you work with our existing acquirer or core banking provider?
Yes. Provider integrations sit behind an interface rather than threaded through the codebase, so adding your acquirer, or running two in parallel for redundancy, is configuration and testing rather than a rewrite.
What does the ledger actually look like?
Double-entry, immutable. Balances are derived from the entry log rather than stored and mutated, writes are idempotent so a retried webhook cannot double-count, and reconciliation runs daily against provider settlement files with discrepancies raised as alerts.
How long does a financial platform take?
A ready-made platform launches in six working days, branded and deployed as it ships. Custom builds run two to eight weeks as a rule, and a regulated financial build sits at the far end of that or beyond it, which we quote in writing before anything starts. Starting from a shipped platform is faster than any of it, because the ledger, onboarding and payment layer already exist. None of these include your licensing or acquirer approval, which is usually the longest item and worth starting immediately.
Do we own the source code?
In full, on both tracks. No per-seat licence, no per-transaction fee to us, no dependency on us to keep operating. You can take the codebase to another team the day after handover.
What is not included?
Licences and regulatory approvals, acquirer and KYC vendor contracts, and the compliance assessment itself. Fraud scoring models are tuned against your traffic after launch rather than shipped pre-trained. We would rather say this now than have you discover it halfway through the build.
Can we start in one market and add others later?
Yes, and we would usually advise it. The platform is built with market as a dimension rather than an assumption, so pricing, payment providers, verification standards, content rules and residency can differ per market. What we resist is launching in four at once, because each additional market multiplies regulator conversations and provider approvals before you have a single paying customer.
How do you handle multi-currency?
Balances are held per currency with FX realized at a defined point rather than implied, and rounding is handled to a stated convention so a fraction never disappears silently. Where a quoted rate has to hold until settlement, the exposure between quote and settlement is modelled explicitly and shown to you, because that gap is a real position somebody is carrying.
What happens if our payment provider goes down?
If you run one provider, you stop taking money until they recover. That is why we build routing and failover as standard and encourage a second provider before you think you need one. The integration cost is roughly a fortnight; the cost of an outage without one is every transaction during it plus the customers who do not return.
Who can see what inside the platform?
Roles are scoped rather than nominal. A support agent handling refunds cannot reach payout approval, a reviewer cannot approve their own KYC case, and configuration changes to limits or thresholds are attributable to a named account with a timestamp. Shared administrator logins defeat all of this, so the model assumes individual accounts from day one.
Can our own engineers take this over?
That is the intended outcome. The stack is deliberately conventional, the documentation set includes the ERD, schema interpretation, API collection and a developer security handbook, and handover includes a walkthrough with your team rather than a repository link and good luck. You own the code outright and can take it to another vendor the day after handover.
What does support look like after launch?
Sixty days of dedicated platform guidance while the first real edge cases arrive, six months of priority bug resolution, and twelve months of updates. Beyond that, extended support and ongoing development are contracted separately rather than bundled into a number that assumes work nobody has scoped. We would rather quote the year you are actually in than sell you three you might not need.
Question not answered here?
Ask us directlyTell us what you are building.
Bring the licence model and the markets. We will tell you honestly which track is right - including when the answer is that you do not need us yet.
A first call takes about thirty minutes and covers four things
Licence or sponsor arrangement
What you hold today, or what you are currently pursuing.
Markets
Where you intend to operate, and in what order.
Client money
Whether it sits on your balance sheet or a partner’s.
Existing systems
What a new platform has to interoperate with on day one.
Those four answers are usually enough for us to tell you which track fits, roughly what it costs, and which provider conversations to start this week rather than next quarter. If the honest answer is that your licence position needs to settle before any build makes sense, we will say that instead of scoping work you are not ready to use.
