Fintech software development: how to build secure financial applications

• Building securely adds roughly a third to a half again on top of an equivalent unregulated build. The part clients underestimate most is compliance evidence, meaning the documentation that proves your controls exist and operate.
• Keeping cardholder data out of your systems is the design decision that saves the most money. The PCI Security Standards Council's guidance says properly segmented systems that only ever hold tokens may fall outside your audit scope, though your assessor makes the final call.
• Authentication is where financial applications are most often weak. NIST's current guidance names passwords, one-time codes, and out-of-band verification as authenticators that are not phishing-resistant.
• Do not build your own payment processing, identity, or compliance infrastructure unless that is your business and you employ a dedicated security team.

In a normal web app, a bug generates a support ticket. In a payments flow, the same class of bug can misdirect real money, and once a regulator or your acquiring bank is involved, you can lose the ability to process at all while you fix it.

IBM's Cost of a Data Breach Report 2026 puts the average cost of a data breach at $4.99 million globally, a record high and a 12% rise from the previous year. In financial services, the average was $6.3 million, around a quarter above the cross-industry figure. Those are averages across large samples, so a seed-stage startup will not see a $6 million bill, but the gap between industries is the useful part.

Scope is where founders misjudge things, and the triggers are simple. Handling card data in any form puts you inside PCI DSS. Enterprise buyers commonly make SOC 2 a condition of signing. If your users initiate payments in the EU or the UK, those flows fall under Strong Customer Authentication rules. Each of these has a lead time measured in months, which is why the sequencing matters as much as the spend.

Four bodies of rules come up in almost every financial build I work on, plus a fifth if you serve European or UK users. They do different jobs, and working out which apply to you is most of the battle.

PCI DSS is the one with hard dates attached. Version 4.0.1 was released in June 2024, and 51 of the 64 new requirements introduced in the version 4 series became effective on March 31, 2025, so the grace period for those is long gone. If a prospective partner describes their PCI knowledge as current while discussing version 3, that indicates how recently they have done this work.

The OWASP Top 10 was reshuffled in November 2025. Broken Access Control stayed at number one and Security Misconfiguration climbed to number two, but the entry worth noticing is Software Supply Chain Failures at number three. This new category broadens the old vulnerable-and-outdated-components entry. It ranked third in the community survey, with exactly 50% of respondents ranking it first, and the handful of CVEs mapped to it carry the highest average exploit and impact scores of any category on the list. Cryptographic Failures and Injection now sit at four and five.

OWASP ASVS is the standard that gets ignored most often and the most useful of the five. Where the Top 10 tells you what tends to go wrong, ASVS gives you a numbered list of requirements you can verify a build against, which is a different thing entirely when you are trying to prove to a customer or an auditor that the work was done. Version 5.0.0 arrived in May 2025. It cut the number of controls required at Level 1 to lower the barrier to a first attempt, and Level 3 now carries around 90 requirements beyond Level 2, up from roughly 20 in version 4.0.3.

The most valuable architectural decision in a payments build gets made before anyone writes code: decide what sensitive data your systems will never hold.

Tokenization does this by having the payment provider hold the real card number and hand your application a token that stands in for it. Your systems store the token, and a stolen token is worthless because the PCI Security Standards Council's Tokenization Guidelines set the bar: "recovery of the PAN value associated with a token must not be computationally feasible through knowledge of only the token, multiple tokens, or other token-to-PAN combinations."

The commercial consequence is what founders should care about. The same guidance states that system components adequately segmented from both the tokenization system and the cardholder data environment, which only ever store, process, or transmit tokens, "may be considered outside of the CDE and possibly out of scope for PCI DSS." Your audit scope shrinks to the systems that genuinely touch card data, and everything else falls outside it.

Vendors oversell this, so be precise about the limits. The Council also says that tokenization "does not eliminate the need to maintain and validate PCI DSS compliance," and the scope reduction only holds if the segmentation is real. A poorly segmented network with tokens flowing across it buys you nothing. Your Qualified Security Assessor decides your final scope, so validate the design with them before you build to it. That supplement dates from 2011 and is still the Council's live guidance, worth knowing when a vendor quotes it selectively at you.

Where you do hold sensitive data, encrypt it in transit and at rest, and be strict about how much you collect. Every field you decide not to store is a control you never have to build, document, or defend.

NIST finalized SP 800-63B-4, Digital Identity Guidelines on July 31, 2025, replacing guidance published in 2017 and last updated in March 2020. It is unusually direct about what does not work, naming four authenticator types that are not phishing-resistant: passwords, lookup secrets, out-of-band authentication, and one-time passwords. Only cryptographic authentication qualifies, and only when it meets the binding requirements in section 3.2.5.

Two of these rules will change your architecture:

• Out-of-band verification over the public telephone network, which covers SMS codes and voice calls, is classified as restricted. NIST says it may revisit that status as the threat picture changes, and the status is heading toward deprecated rather than away from it.
• NIST does not permit syncable authenticators, the category most consumer passkeys fall into, at AAL3, because the private key can be exported to another device. They remain acceptable at AAL2, which is where most consumer fintech products sit.

For the applications I build, that resolves to OAuth 2.0 and OpenID Connect for the authentication and authorization layer, with phishing-resistant factors on anything privileged. If your product moves money, treat SMS as a fallback you plan to retire.

European and UK payment flows add a further requirement. Under PSD2, customer-initiated electronic payments in the EU generally need Strong Customer Authentication: two independent elements drawn from something the user knows, something they have, and something they are. The European Banking Authority publishes the technical standards. The UK retained an equivalent regime after leaving the EU, now set out in the Payment Services Regulations 2017 and the UK SCA rules, supervised by the FCA, and the two regimes have already begun to diverge on points such as which inherent elements count. Read the exemptions against your own flows before trusting a summary. PSD3 and the accompanying Payment Services Regulation are working through the EU legislative process and will change these obligations again, so build for the rules to move.

You can tell within the first sprint whether a team builds security in or bolts it on, because it shows up in whether the pipeline runs security checks on every commit or only when someone remembers.

On my projects, that workflow runs on four things:

• static and dynamic application security testing, against both the code and the running application
• dependency scanning, which matters more now that OWASP has moved supply chain failures to third on its list
• penetration testing before release, not after a customer asks for the report
• ASVS underneath all of it as the requirement list the testing is checked against

Any competent team can name those four. What separates them is whether the checks run automatically on every change or get performed once, in a rush, the week before launch, and whether anyone has written down which ASVS requirements the build is being held to.

The 30% to 50% premium I opened with covers design, implementation, and testing. It does not cover the audits and attestations your customers will ask for, which are a separate line item with their own timeline.

The SOC 2 figures come from soc2auditors.org, a specialist directory that compares pricing across 173 audit firms and was updated in May 2026. It is an aggregator, not a standards body, and audit pricing is published inconsistently across jurisdictions, so treat it as a planning range and get quotes from two or three firms before you budget for it.

Compliance evidence is what clients underestimate most. Writing secure software is only half the job, and the other half is demonstrating to an auditor that your controls are in place and operating, which is a different discipline with its own overhead. A team that has never assembled an evidence pack will underestimate that half every time.

The most common mistake is the belief that security can be added later. Security is not a feature you bolt on at the end. It is a way of building the product from day one, and retrofitting it means architecture changes, redesigns, and compliance work that would have cost a fraction of the price if the decisions had been made at the start. I see that mindset most often in fintech projects that were started without security experience on the team.

A team stores card numbers because it is the fastest path to a working prototype, only to discover that its entire infrastructure now falls within PCI scope. Fixing that means introducing a tokenization provider, migrating everything already stored, then re-architecting and re-testing every system that reads it.

The smaller errors cluster around data handling, and three of them show up regularly in code I inherit:

• verbose logging that captures sensitive fields nobody meant to store
• collection of personal data the product has no use for
• permissive access control between internal services, where one service trusts another's claims about who the user is

That last one is why Broken Access Control ranked first in both the 2021 and 2025 OWASP lists. In financial applications, it is rarely an exotic exploit. It is an internal endpoint that never checks whether the caller is entitled to the account it is requesting.

Never build your own payment processing or compliance infrastructure unless those things are your core business and you have a dedicated security team. Use proven providers for payments, identity, and compliance, then spend your engineering effort on the product that differentiates you.

It comes down to who carries the certification burden. Providers such as Stripe, Adyen, and Auth0 employ compliance teams whose full-time job is keeping attestations current against standards that change on their own schedule, not yours. When a startup rebuilds card vaulting to save on processing fees, the savings usually evaporate twice over. Once in the build itself, and again in the assessor time the newly in-scope infrastructure creates at every annual review.

Your engineering budget belongs in the parts of the product a provider cannot supply, which means your data model and your workflows, plus whatever it is about the product that made someone fund it in the first place.

Ask one question: "How do you make sure our application never stores or exposes sensitive payment data, and which security standards do you follow?"

A team with real fintech experience answers immediately and concretely. They go straight to PCI scope and how they would keep card data out of your systems, and they ask you questions back about your data flows, because they cannot answer properly without knowing them. A team that cannot explain its process in those terms has not built financial software before.

Ask how they have handled a compliance requirement before, even anonymized. How a team approached scope reduction, or what a pre-release penetration test turned up, tells you far more than a case study headline.

What does a fintech software developer do differently?

The same things a good web developer does, plus constraints that shape the architecture from the first design session. Those constraints decide where sensitive data is allowed to live and which authentication factors are acceptable under NIST guidance. They also mean the evidence trail gets built as the work happens, because assembling it afterward costs far more.

Do I need to be PCI compliant if I use Stripe or Adyen?

Yes, though the scope can be very small. A provider that keeps card data off your servers reduces what you have to prove, but obligations remain, and how small your scope becomes depends on your integration method. Have a Qualified Security Assessor confirm it.

How long does it take to build a secure fintech application?

Add three to four weeks to an eight-week feature for the security and compliance work, then plan separately for audits. A SOC 2 Type 2 observation window alone runs 3 to 12 months, so if a contract depends on the report, that clock starts long before you need it.

Is SOC 2 or PCI DSS more important?

They answer different questions, and most fintech companies selling to businesses end up needing both. PCI DSS applies if you handle card data and is not optional. SOC 2 is what enterprise buyers ask for when they are assessing whether to trust you with their business.

What is the cheapest way to reduce security cost?

Decide early what data you will never hold. Every category of sensitive data you keep out of your systems removes the need to build, document, and defend controls in an audit.

• IBM, Cost of a Data Breach Report 2026. https://www.ibm.com/reports/data-breach. Cited for the $4.99 million global average breach cost, described by IBM as a record high and a 12% year-on-year rise.
• IBM Newsroom, IBM Study: One in Four Malicious Breaches are AI-Enabled, July 29, 2026. https://newsroom.ibm.com/2026-07-29-ibm-study-one-in-four-malicious-breaches-are-ai-enabled,-costing-companies-6-million-on-average. Cited for the $6.3 million average in financial services.
• PCI Security Standards Council, Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x. https://blog.pcisecuritystandards.org/now-is-the-time-for-organizations-to-adopt-the-future-dated-requirements-of-pci-dss-v4-x. Cited for v4.0.1's June 2024 release and for 51 of the 64 new requirements taking effect March 31, 2025.
• PCI Security Standards Council, Information Supplement: PCI DSS Tokenization Guidelines, v2.0, August 2011. https://listings.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf. Cited for the computational-infeasibility requirement, the out-of-scope condition for adequately segmented token-only systems, and the statement that tokenization does not remove the obligation to validate compliance. This is guidance, not a normative PCI DSS requirement.
• OWASP Foundation, A03:2025 Software Supply Chain Failures. https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/. Cited for the category's position, the 50% community-survey ranking, and its exploit and impact scores. Full list at https://owasp.org/Top10/2025/.
• OWASP Foundation, Application Security Verification Standard, v5.0.0. https://owasp.org/www-project-application-security-verification-standard/. Cited for the version and release date of May 30, 2025, and the three-level structure.
• SoftwareMill, What's New in ASVS 5.0. https://softwaremill.com/whats-new-in-asvs-5-0/. Cited for the Level 1 rebalancing and for Level 3 carrying roughly 90 requirements beyond Level 2, against about 20 in version 4.0.3. Secondary analysis of the standard.
• NIST, SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management. https://pages.nist.gov/800-63-4/sp800-63b.html. Cited for the July 31, 2025 finalization, the four authenticator types stated not to be phishing-resistant, the restricted status of PSTN out-of-band verification, and the prohibition on syncable authenticators at AAL3.
• European Banking Authority, regulatory technical standards on strong customer authentication under PSD2. https://www.eba.europa.eu/regulation-and-policy/payment-services-and-electronic-money. Cited for the EU requirement and its exemptions.
• Financial Conduct Authority, Strong Customer Authentication. https://www.fca.org.uk/firms/strong-customer-authentication. Cited for the UK's separate retained regime.
• soc2auditors.org, SOC 2 Type 2 Audit Cost. https://soc2auditors.org/insights/soc-2-type-2-audit-cost/. Cited for the $15,000 to $45,000 audit fee range for a startup under 50 employees on a security-only scope, and the 3 to 12 month observation window. A specialist directory covering 173 audit firms, updated May 2026. Secondary source, not a standards body.

This article is written from the perspective of a software development company and is intended as general guidance on building secure financial applications. It is not legal, financial, or compliance advice. Your obligations under PCI DSS, SOC 2, PSD2, the UK SCA rules, or any other regime depend on your business, your data flows, and your jurisdiction. Confirm them with a Qualified Security Assessor, an auditor, or qualified legal counsel before you rely on them.