Passing a fintech security review: the engineering readiness checklist

A security review asks whether your engineering is in order; it is not a certificate, and this checklist does not grant one. Reviewers look for access control that holds, secrets kept out of code, logging you can audit, a money path that cannot double-count, and data handled carefully. Prepare against OWASP guidance, fix what you find, and be honest about what still needs a certified assessor.

What this is not. This is engineering readiness, not a PCI, SOC 2 or ISO attestation, and not a certified penetration test. Application security testing against OWASP guidance finds many real issues, but it produces no compliance pass. Where a reviewer, regulator or partner requires a certified pentest or an attestation, you need an accredited assessor, and licensing questions are for your adviser: this is general information.

If you would rather have readiness tested for you, see how RAITHub would test it at the end of this guide.

What is a fintech security review actually checking?

That the obvious ways to lose money or data are closed. Most reviews walk the same ground, and most of it maps to the OWASP Top 10 and the Web Security Testing Guide. The 2025 edition keeps broken access control as the first category, which is where fintech reviews spend most of their time.

Area	What the reviewer asks	Reference
Access control	Can one user reach another's account, balance or transactions?	OWASP A01
Authentication	Strong auth, sensible sessions, no password reset holes	OWASP cheat sheet
Secrets	Keys and credentials out of the repo and rotated	OWASP cheat sheet
Logging and alerting	Can you reconstruct who did what, and are failures noticed?	OWASP A09
The money path	Idempotency, no double-charge, a balanced ledger	Engineering practice
Data handling	Encryption in transit and at rest, least data held	Engineering practice

What is the engineering readiness checklist?

Go through these before anyone external looks. Each is a concrete thing a reviewer can test, and each is something you can fix.

• Every endpoint checks ownership, not just that the user is logged in. The classic fintech failure is an authenticated user reading another account by changing an ID in the URL. The fix is in the IDOR prevention cheat sheet.
• Authorization is enforced server-side, in one place, and tested. Hiding a button is not access control.
• No secrets in the repository or client bundle. Keys live in environment configuration or a secrets manager, and are rotated.
• The money path is idempotent and modelled correctly. Retries, double clicks and replayed webhooks cannot double-charge, per stopping duplicate payments and our payments engineering guide.
• The ledger is enforced, not hoped. Balance is checked in the database, as in repairing an out-of-balance ledger.
• An audit log records sensitive actions — who, what, when — and cannot be silently edited. See the logging cheat sheet.
• Input is validated and queries are parameterised. No string-built SQL anywhere on the money path.
• Rate limiting on auth and payment endpoints, so card testing and credential stuffing are throttled.
• Dependencies are current, with a way to see and patch known-vulnerable packages.
• Data is encrypted in transit and at rest, and you hold the minimum you need.

How do you prove access control instead of claiming it?

With tests that try to break tenant and account isolation and assert they fail. A reviewer trusts a passing suite far more than a sentence in a document. The pattern is one test per cross-account attempt.

// Prove account isolation: user A must never read user B's transactions.
test('a user cannot read another account transactions (IDOR)', async () => {
  const alice = await signInAs('alice')
  const bobAccountId = await createAccountFor('bob')

  const res = await alice.get('/api/accounts/' + bobAccountId + '/transactions')

  expect(res.status).toBe(403) // not 200 with Bob's data, not 404 leaking existence
})

test('changing the account id in a transfer is rejected server-side', async () => {
  const alice = await signInAs('alice')
  const bobAccountId = await createAccountFor('bob')

  const res = await alice.post('/api/transfers', {
    fromAccountId: bobAccountId, // Alice tries to move Bob's money
    amountMinor: 1000,
  })

  expect(res.status).toBe(403)
})

Write one of these for every object a user could try to reach by guessing an ID: accounts, transactions, statements, disputes. When these run in CI, access control is enforced on every change, not just the day of the review.

What does a review not cover, and when do you need more?

Be explicit about the boundary so nobody mistakes readiness for a pass.

You have	You do not yet have	Who provides it
OWASP-level application security testing	A certified penetration test	An accredited pentest firm
Engineering readiness evidence	A SOC 2 or ISO 27001 report	An accredited auditor over a defined period
Secure handling of card data in your design	A PCI DSS attestation	A QSA, against the PCI DSS standard
Tests and controls you can show a partner	A licence to operate a regulated activity	Your regulator, via your adviser

A common and honest answer to "are you PCI compliant?" early on is to not store card data at all: use a gateway's hosted fields so card numbers never touch your servers, which keeps most of PCI out of your scope. Whether that satisfies a specific partner is still a question for your adviser.

Buy, build or hire?

Option	Example	Choose this when	Where it stops
Automated scanners	Dependency and vulnerability scanners in CI	Catching known issues continuously and cheaply	Miss logic flaws like broken access control
Self-review checklist	This checklist plus OWASP guides	Early stage, small surface, limited budget	No independent eyes; blind spots stay hidden
Application security testing	OWASP-level testing by a QA team	You want readiness evidence before a partner review	Not a certified pentest or attestation
Accredited assessment	A certified pentest or SOC 2 audit	A partner or regulator requires the certificate	Cost and lead time; still needs engineering ready first

How long does readiness take to prepare yourself?

Our estimate, for a developer who knows the codebase: one to two weeks to work the checklist, add access-control tests, move secrets out and tighten logging and rate limits, longer if access control is scattered and has to be centralised first. The main risk of doing it alone is confirmation bias: the person who wrote the code is the worst placed to find the account they forgot to scope. Independent testing exists for exactly that reason.

How RAITHub would test this

• Readiness review: walk the checklist against your codebase and report each gap with its fix, mapped to OWASP references.
• Access-control tests: cross-account and cross-tenant tests that assert isolation, run in CI.
• Money-path checks: idempotency, no double-charge, and a ledger balance enforced in the database.
• Honest scope: a written report that states plainly what is OWASP-level testing and what still needs a certified assessor.

Timeline: a fixed-price readiness audit is days to two weeks depending on size; remediation is scoped from what it finds. What you receive: a written report with each issue and its fix, access-control tests in CI, handover docs, and full IP under NDA. This is application-level security testing against OWASP guidance; it is not a CREST- or PCI-certified penetration test and produces no compliance attestation. Production and financial data stay in your own cloud account; testing uses synthetic data. Licensing and regulatory questions are for your adviser: this is general information.

Proof we can point to: this site runs 400+ automated tests with security headers and rate limiting without Redis, and Sundor Skin enforces row-level security and credit rules in PostgreSQL across 146 tables under 530+ tests. Next step: a free 15-minute technical audit, then a written fixed quote. Book a security readiness audit. More is on the security testing page and the FinTech page.

Frequently asked questions

Does passing a security review mean I am PCI or SOC 2 compliant?

No. A security review and OWASP-level testing check that your engineering is in order and find real issues, but they produce no compliance attestation. PCI DSS, SOC 2 and ISO 27001 require accredited assessors or auditors over a defined scope and period. Confirm what your partner needs with your adviser.

What do fintech security reviewers look at most?

Access control. The most common and most damaging fintech flaw is an authenticated user reaching another account by changing an ID. Reviewers spend most of their time there, which is why broken access control is the first category in the OWASP Top 10.

How do I prove access control works?

With automated tests that attempt cross-account and cross-tenant access and assert they are rejected server-side, run in CI. A passing suite is far more convincing than a claim in a document, and it keeps isolation enforced on every change.

Is OWASP-level testing the same as a penetration test?

Application security testing against OWASP guidance overlaps with a pentest but is not a certified one. Where a partner or regulator requires a certified penetration test or an attestation, you need an accredited firm; readiness testing gets your engineering in shape first.

How can I reduce my PCI scope?

Often by never storing card data: use a gateway's hosted fields so card numbers never touch your servers, which keeps most of PCI out of scope. Whether that satisfies a specific partner or regulator is a question for your adviser.