Fintech software development costs $120,000 to $250,000 for a payments-enabled product, $300,000 to $700,000 for a lending or banking platform, and $800,000+ for fully regulated products. Compliance accounts for 25–40% of the total, and it is the portion most budgets omit. The three regimes that shape architecture are PCI DSS for card data, PSD2 and strong customer authentication for European payments, and open banking standards for account connectivity. Below is what each requires in engineering terms.
Key Takeaways
- Compliance is 25–40% of a fintech budget, not a line item at the end.
- PCI DSS scope reduction is the highest-leverage architectural decision you will make. Never letting card data touch your infrastructure reduces the assessment from hundreds of controls to roughly thirty.
- PSD2 strong customer authentication applies across the EEA and UK; the exemptions matter as much as the rule, because applying SCA to every transaction destroys conversion.
- UK open banking is far more consistent than EU open banking, because the UK mandated a common standard and PSD2 did not.
- Build your ledger; buy everything else. Double-entry ledgering is core. KYC, AML, card processing and bank connectivity are not.
- Money never moves on a single database write. Idempotency, immutability and reconciliation are the non-negotiable primitives.
PCI DSS: Scope Reduction Is Everything
PCI DSS v4.0 replaced v3.2.1, and its future-dated requirements became mandatory on 31 March 2025. Version 4.0.1 is the current revision. If you touch card data, it applies — it is a contractual obligation imposed by the card networks, not legislation, but non-compliance carries fines, higher processing fees and potential loss of processing ability.
The critical insight is that PCI DSS burden is determined almost entirely by scope, and scope is an architectural choice you make on day one.
| Approach | Card data touches your systems? | Validation | Relative cost |
|---|---|---|---|
| Hosted payment page / redirect | No | SAQ A (~30 questions) | Lowest |
| Hosted fields / iframe (Stripe Elements) | No | SAQ A | Low |
| Direct post to processor | Briefly, in browser only | SAQ A-EP | Moderate |
| Card data on your servers | Yes | SAQ D or full ROC | Very high |
Use hosted fields. Stripe Elements, Adyen Components, Braintree Hosted Fields and equivalents render inputs inside an iframe served by the processor. The card number never enters your DOM or your network. This single decision is the difference between a compliance exercise a small team can complete and one requiring a Qualified Security Assessor, network segmentation, quarterly ASV scans and annual penetration testing.
If you genuinely must handle raw card data — because you are building a processor or gateway — budget an additional $150,000–400,000 and twelve months, and engage a QSA before you write architecture, not after.
Things v4.0 tightened that catch teams out: multi-factor authentication for all access into the cardholder data environment, stricter password requirements, mandatory scripts inventory and integrity monitoring on payment pages, and targeted risk analyses for several controls. Also note the anti-pattern that ruins scope: logging full card numbers, even accidentally, even briefly. Redact at the boundary and test that you have.
PSD2 and Strong Customer Authentication
PSD2 governs electronic payments across the European Economic Area, and the UK retains an equivalent regime post-Brexit. Its most visible engineering consequence is strong customer authentication.
SCA requires two of three independent factors:
- Knowledge — a password or PIN
- Possession — a device, hardware token or app
- Inherence — a fingerprint or facial recognition
Independence matters: a one-time code sent by SMS to the same device where the payment is being made is weak, and a password plus a security question is not two factors at all.
The exemptions are as important as the rule. Applying SCA to every transaction will damage your conversion rate badly. The regime provides for:
| Exemption | Condition |
|---|---|
| Low value | Under €30, with cumulative limits |
| Recurring transactions | Same amount, same payee, after initial SCA |
| Trusted beneficiaries | Payee whitelisted by the customer |
| Transaction risk analysis | Below fraud-rate thresholds, at the provider’s risk |
| Merchant-initiated transactions | Where the customer is not present |
Engineering implication: build your payment flow so authentication is a conditional step evaluated per transaction, not a fixed part of the sequence. Retrofitting a conditional 3-D Secure step into a linear checkout flow is painful and always happens under time pressure.
PSD3 and the Payment Services Regulation were proposed in 2023 and remain in the EU legislative process. They tighten fraud liability and improve open banking API standards. Design for change rather than assuming today’s rules are permanent.
Open Banking
Open banking lets licensed third parties access account data and initiate payments with the customer’s consent. Two roles matter:
- AISP (Account Information Service Provider) — read account data. Powers budgeting apps, affordability checks, accounting reconciliation.
- PISP (Payment Initiation Service Provider) — initiate payments directly from the customer’s bank account, bypassing card networks and their fees.
The UK and EU differ significantly, and this catches people out. The UK’s Competition and Markets Authority mandated a common Open Banking Standard implemented by its largest banks, so integration behaves consistently. PSD2 mandated access across the EEA but not a standard, so implementations differ by bank and by country — Berlin Group, STET and various national schemes coexist. Building EU-wide open banking connectivity directly is a substantial undertaking.
The pragmatic path for most products is an aggregator — TrueLayer, Tink, Plaid, Yapily, GoCardless and others — which normalises the differences and, importantly, holds the regulatory permissions. Building direct connectivity is justified only at high volume, where the aggregator’s per-call pricing exceeds the cost of maintaining the integrations yourself.
For North American readers: the US and Canada have historically relied on screen-scraping and bilateral data-sharing agreements rather than a mandated standard. The CFPB’s Section 1033 rulemaking moves the US toward a more formal open banking framework, and Canada has been developing a consumer-driven banking framework. Both are evolving; check the current position before designing to either.
Architecture Non-Negotiables
Financial software has a small set of properties that are not optional, regardless of what you are building.
Double-entry ledger. Every movement of value is two entries that sum to zero. Not a balance column that gets updated — an immutable, append-only record of entries from which balances are derived. This is the single most important design decision in a fintech system, and retrofitting it later is close to a rewrite. Never delete or update a ledger entry; correct with a reversing entry.
Idempotency everywhere. Every mutating endpoint accepts an idempotency key and returns the original result on retry. Networks fail mid-request; clients retry; users double-click. Without idempotency, one of those becomes a duplicate payment, and duplicate payments are how fintech companies lose customers permanently.
Reconciliation as a first-class system. Automated daily reconciliation between your ledger and every external system — processor, bank, card network — with a defined break-investigation process. Not a report someone reads occasionally. A system with alerts and an owner.
Immutable audit logging. Who did what, when, from where, with what result. Write-once storage. Regulators and auditors will ask, and “we can reconstruct it from the application logs” is not an answer.
Precise decimal arithmetic. Never floating point for money. Use integer minor units or a decimal type. Define rounding rules explicitly and apply them consistently — a rounding inconsistency between two services produces breaks that take days to find.
Encryption and key management. TLS 1.2 minimum in transit, AES-256 at rest, and a managed KMS or HSM for keys. Not keys in environment variables.
Cost and Timeline
| Product type | Cost | Timeline |
|---|---|---|
| Payments-enabled SaaS (hosted processor) | $120,000–250,000 | 5–9 months |
| Digital wallet / P2P transfers | $250,000–500,000 | 8–14 months |
| Lending platform (KYC, scoring, servicing) | $300,000–700,000 | 10–16 months |
| Open banking data product | $200,000–450,000 | 7–12 months |
| Neobank / full banking platform | $800,000–2,500,000+ | 14–30 months |
Compliance-specific costs on top:
| Item | Cost |
|---|---|
| PCI DSS SAQ A (self-assessment) | $5,000–20,000 |
| PCI DSS Level 1 with QSA | $60,000–200,000+ |
| SOC 2 Type II | $30,000–80,000 first year |
| Penetration testing | $15,000–50,000 annually |
| KYC/AML vendor | $0.50–5.00 per verification |
| Open banking aggregator | $500–10,000+ monthly |
For a fuller picture of how these figures compare to non-regulated builds, see our 2026 software development rate guide.
Build vs Buy
The rule is simple: build what encodes your business logic; buy what encodes someone else’s compliance obligation.
| Component | Recommendation |
|---|---|
| Card processing | Buy — Stripe, Adyen, Checkout.com |
| KYC / identity verification | Buy — Onfido, Persona, Jumio |
| AML / sanctions screening | Buy — ComplyAdvantage, Napier |
| Bank connectivity | Buy — TrueLayer, Tink, Plaid |
| Core ledger | Build — this is your product |
| Business rules and pricing | Build — this is your differentiation |
| Fraud detection | Both — vendor baseline plus your own signals |
| Customer-facing UX | Build |
Every “buy” above transfers a compliance burden to a vendor whose entire business is carrying it. That is worth paying for.
How NSDBytes Approaches Fintech Builds
We treat the compliance surface as an architecture input from week one, because every one of the requirements above is expensive to retrofit and cheap to design in.
- Scope reduction first. Before any implementation, we map exactly where regulated data flows and design to keep it out of client-controlled systems wherever possible.
- Ledger before features. The double-entry model gets built and tested before anything that depends on it.
- Idempotency and reconciliation as platform primitives, not per-feature additions.
- Evidence generated continuously. Audit logs, access reviews and change records are produced by the system as it runs, so an assessment is an export rather than a project.
Our fintech product development and quality assurance teams work together on these builds, because in financial software the test suite is the compliance evidence.
We are engineers, not a law firm or a QSA — you will need both. What we can do is build a system that makes the compliance position demonstrable.
Final Thoughts
The fintech products that ship on budget are the ones that made three decisions early: keep card data out of scope, build a proper double-entry ledger, and buy every commodity compliance component. The ones that overrun almost always made the opposite choices and discovered the cost during an audit.
If you are building a financial product and want the architecture reviewed against these requirements before you commit a budget, talk to our team.
