Building a fintech product: security and reliability requirements

A fintech product differs from an ordinary web service in the cost of mistakes: a lost or duplicated payment, a data leak or a few hours of downtime cost customers' money and trust, sometimes even a licence. So precise money accounting, a full audit trail, strict access control, resilience and industry compliance — from PCI DSS to regulators' rules — are built in from day one.

Here are the requirements fintech products face and how to address them in architecture and process.

How does fintech development differ from an ordinary product?

Fintech development differs in that reliability and security are not qualities "for later" but core requirements from day one. Every money operation must be accurate, traceable and reproducible, and the system must keep working when individual components fail.

Area	Ordinary product	Fintech product
Money accounting	An amount on the order	Double-entry; balances reconcile to the cent
Operation log	Logs for debugging	An immutable audit ledger
Staff access	Roles in the admin panel	Least privilege, approval for critical actions
Availability	Downtime is undesirable	Downtime is measured in money and penalties
Production changes	Deploy when ready	Change control, review, rollback capability
Regulation	General data rules	Industry standards and regulator requirements

How should money be stored and calculated?

Store money as integers in the currency's minor units or in exact decimal types, never floating-point numbers, and account for it with double-entry bookkeeping: every operation is a posting that debits one account and credits another. The balance is not a mutable number but is calculated from, or reconciled against, the postings.

CREATE TABLE ledger_entries (
    id             bigserial PRIMARY KEY,
    transaction_id uuid        NOT NULL,
    account_id     bigint      NOT NULL REFERENCES accounts(id),
    amount         bigint      NOT NULL,  -- in cents; debits are negative
    currency       char(3)     NOT NULL,
    created_at     timestamptz NOT NULL DEFAULT now()
);

-- Check: the postings of every transaction sum to zero
SELECT transaction_id FROM ledger_entries
GROUP BY transaction_id HAVING sum(amount) <> 0;

Rules for operations

1. Every operation is idempotent — a repeated request does not create a second posting.
2. Ledger entries are never updated or deleted; a mistake is corrected with a reversing entry.
3. Balance operations run in transactions with locks to rule out race conditions.
4. Daily reconciliation with banks and payment providers.

We covered protecting against double charges at the API and webhook level in idempotent payments and webhooks.

Photo: Unsplash

Which security requirements apply to fintech?

Fintech faces requirements for data protection, access control and logging, some of them codified in industry standards. If the product stores or processes card data, PCI DSS applies; in the European Union the Digital Operational Resilience Act (DORA) applies to financial entities; other jurisdictions have their own central bank or regulator rules.

Baseline measures almost every fintech product needs:

• card data never touches your servers — a certified provider handles it;
• encryption of sensitive data at rest and in transit;
• two-factor authentication for customers, and mandatory for staff;
• least privilege and a second person's approval for critical actions;
• an immutable log of user and staff actions;
• regular penetration tests and external audits.

General web application vulnerabilities and defences are covered in OWASP Top 10 explained. The exact set of mandatory requirements depends on your licence and jurisdiction, so define it with legal and compliance specialists before development starts.

How do you ensure reliability and availability?

Fintech reliability comes from redundancy of every critical component, well-designed behaviour when external services fail, and observability so the team hears about problems before customers do. For each service, define in advance the acceptable downtime and acceptable data loss.

What goes into the architecture:

1. Database replicas with automatic failover.
2. Backups with regular restore tests.
3. Queues and retries for calls to banks and providers, which are sometimes unavailable.
4. Monitoring of business metrics — successful payments per minute — not just servers.
5. An incident response plan and drills to practise it.

How do you organise the fintech development process?

The fintech development process is built around change control: every change goes through review, automated tests and security checks, and each deployment is documented and can be rolled back quickly. Developer access to production data is restricted and logged.

What the process usually includes:

• mandatory code review, with two reviewers for money logic;
• automated tests for every money flow, including errors and retries;
• separate environments and data: developers do not work with real customer data;
• automated dependency and secret scanning in CI;
• documented releases with rollback capability.

In short

• In fintech a mistake costs customers' money and trust, so reliability and security are built in from day one.
• Store money as integers in minor units, use double-entry accounting and never alter the ledger.
• Leave card data to a certified provider and define PCI DSS and regulatory requirements up front.
• Redundancy, tested backups, queued external calls and business-metric monitoring are mandatory.
• The process revolves around change control: review, tests, security checks and rollback.