The fintech security checklist for launch, growth, and enterprise review

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs Comprehensive Security Partner (CSP)

How to use this checklist

Review the production design and the release candidate. A control passes after the team tests the real path and saves evidence. A ticket, policy, diagram, or verbal answer does not prove that the control works.

1. Name the scope. List every mobile app, web app, API, admin tool, cloud account, payment provider, identity provider, user role, and environment included in the release.
2. Assign owners. Put one name beside every section. Shared ownership hides unfinished work.
3. Test each control. Use two customer accounts, every staff role, changed API requests, failed provider responses, repeated payment events, and concurrent transaction requests.
4. Save evidence. Record the date, environment, tester, result, request, response, screenshot, log entry, configuration, and related pull request.
5. Grade the result. Use Pass, Fail, Partly complete, Accepted risk, or Outside scope. Add a deadline to every result except Pass and Outside scope.
6. Retest every fix. Repeat the original test after deployment. Close the item after the new evidence shows the control working.

Release blockers

These failures expose the core of a fintech product. Stop the release and fix them before launch.

• Account access: A user reaches another user’s account through login, recovery, OTP, device change, or session reuse.
• Object access: A customer reads or changes another customer’s wallet, card, loan, beneficiary, document, profile, or transaction.
• Role access: A customer or junior staff account reaches an admin, finance, compliance, support, or infrastructure action.
• Money creation: A request credits value without a confirmed source, valid transaction, and matching ledger entries.
• Double processing: A repeated request, callback, retry, or race condition creates a second debit, credit, payout, refund, reward, or reversal.
• Webhook trust: A forged or changed provider event updates a balance or transaction.
• Secret exposure: A production key, signing secret, database credential, private key, or privileged token is present in client code, logs, source control, or public storage.
• Private data exposure: An API, export, log, file URL, backup, or storage bucket exposes customer data without the required access check.
• Public production services: A database, cache, queue, admin port, internal dashboard, or cloud control service accepts traffic from the public internet.
• Missing response path: The team has no tested way to revoke sessions, rotate keys, disable a provider, freeze risky transactions, restore data, and contact the people responsible for an incident.

1. Authentication and account recovery

Authentication proves who controls an account. Review registration, login, OTP, password reset, PIN reset, biometric unlock, new-device approval, email change, phone-number change, and support-led recovery as one system. The weakest path grants access.

• Registration abuse: Rate-limit account creation by identity, phone number, email address, device, IP address, and network range. Detect repeated attempts that rotate one value while reusing the rest.
• User enumeration: Return the same public response for registered and unregistered accounts during login, recovery, OTP request, and invite flows. Review response time and response body.
• Password storage: Store passwords with a current password-hashing function and a unique salt. Keep application passwords out of logs, analytics, support tools, and error reports.
• OTP generation: Generate OTP values with a cryptographically secure random source. Give each code one purpose, one account, one short validity window, and a strict attempt limit.
• OTP abuse: Rate-limit OTP generation and validation separately. Add backoff after failed checks. Track cost and delivery volume so SMS bombing produces an alert.
• OTP replay: Mark a code as used through an atomic server-side update. A successful code must fail on the next request.
• Phishing-resistant access: Use WebAuthn or another phishing-resistant method for staff and high-value customer actions. Manual OTP entry does not provide phishing resistance. See the current NIST authentication guidance.
• Recovery ownership: Require account-bound verification. Knowledge of a name, phone number, date of birth, BVN digits, or recent transaction does not prove control.
• Recovery alerts: Notify the customer through an existing trusted channel after a password, PIN, phone number, email address, authenticator, or trusted device changes.
• Sensitive changes: Require fresh authentication before changing identity details, security settings, payout accounts, trusted devices, API keys, or transaction limits.
• Support recovery: Give support staff a written flow with required evidence, approval rules, audit logs, and blocked actions. Support must never ask for a password, PIN, OTP, recovery code, or full card number.
• Biometric unlock: Store the cryptographic key in Android Keystore or iOS Keychain. The server verifies a signed challenge. A client-side biometric success flag must never authorize a server action.

Evidence to keep: rate-limit tests, OTP replay tests, recovery test cases, authenticator settings, password hashing configuration, session revocation logs, and customer notification records.

2. Sessions and trusted devices

A secure login loses its value when a stolen session stays active. Treat access tokens, refresh tokens, cookies, device keys, and staff sessions as credentials.

• Token content: Keep secrets and private customer data out of client-readable tokens. Sign every token with an approved algorithm. Reject unsigned tokens and algorithms outside the approved list.
• Token validation: Check signature, issuer, audience, subject, expiry, purpose, token type, and revocation state on every protected request.
• Browser storage: Store browser session secrets in cookies with HttpOnly, Secure, and the required SameSite setting. Add Cross-Site Request Forgery protection to state-changing requests.
• Mobile storage: Store refresh tokens and device keys in Android Keystore or iOS Keychain. Keep tokens out of plain preferences, SQLite, logs, crash reports, screenshots, and clipboard data.
• Rotation: Rotate refresh tokens after use. Detect reuse of an older token and revoke the related session family.
• Logout: Revoke the server-side session. Clearing local storage alone leaves a copied token active.
• Security-event revocation: Revoke affected sessions after password reset, PIN reset, account recovery, authenticator removal, trusted-device removal, staff termination, and confirmed account compromise.
• Timeouts: Define inactivity and overall session limits from the risk of each role and action. Require fresh authentication before high-value actions. Record the limits in the security design.
• Device list: Show customers their active devices and recent sessions. Give them a direct way to revoke an unknown device.
• Session anomaly: Alert on token reuse, impossible travel, sudden device change, abnormal network change, and access after a revocation event.

3. API authorization

Authorization decides what an authenticated user can read and change. OWASP lists Broken Object Level Authorization as API1 in the 2023 API Security Top 10. UUIDs hide sequence; ownership checks enforce access.

• Server identity: Derive the current user, tenant, staff role, and device trust from validated server-side authentication. Ignore client claims that try to set these values.
• Ownership in every query: Include the current owner or tenant in the database query for each wallet, card, account, loan, beneficiary, document, transaction, dispute, notification, and export.
• Every operation: Test list, read, create, update, delete, approve, cancel, export, share, retry, download, and bulk actions. A read check does not protect an update route.
• Two-user test: Create User A and User B. Replace every object identifier in User A’s requests with User B’s identifiers. Test URL paths, query values, headers, JSON bodies, GraphQL variables, file names, and signed links.
• Role matrix: List each customer and staff role against each action. Enforce the matrix in a shared server-side policy. Deny access when a role or rule is missing.
• Property control: Allowlist fields accepted from the client. Reject attempts to set role, verification state, balance, limit, fee, owner, approval state, internal note, risk score, or system timestamps.
• Response control: Return the fields required by the screen. Remove internal IDs, provider payloads, secrets, risk notes, document paths, and private profile fields.
• Tenant separation: Apply tenant scope to queries, caches, background jobs, exports, object storage paths, search indexes, analytics data, and support tools.
• Signed URLs: Give private file links a short expiry, narrow object scope, and authorization check before issue. A changed object path must fail.
• API inventory: Keep one current list of public, partner, mobile, staff, webhook, and internal endpoints. Remove old versions or apply the same controls and monitoring.

4. Transactions and ledger integrity

Money movement needs one trusted server-side state machine. Each transfer, card payment, withdrawal, deposit, refund, reversal, fee, reward, loan disbursement, and settlement must move through named states with allowed transitions.

• Server calculations: Calculate amount rules, fees, discounts, exchange rates, commissions, limits, tax, and final value on the server. Treat client values as requests.
• Money type: Store money with integer minor units or an exact decimal type. Define currency beside every value. Reject floating-point calculations in ledger logic.
• Positive bounds: Reject zero, negative, out-of-range, over-limit, malformed, unsupported-currency, and precision-breaking values before creating a transaction.
• Atomic write: Complete the balance check, limit check, journal entries, state change, and idempotency record inside one database transaction.
• Concurrency control: Use row locks, serializable transactions, atomic conditional updates, or a proven ledger design. Send concurrent requests against the same available balance and confirm that total spending never exceeds it.
• Idempotency: Require a unique key on every value-changing request. Bind the key to the user, endpoint, and request hash. Return the first result for a matching retry. Reject the same key with a changed request.
• State transitions: Define allowed paths such as created → pending → successful and pending → failed. Reject direct jumps, repeated completion, and changes from a final state.
• Ledger entries: Record balanced debit and credit entries for every movement of value. Keep journal entries immutable. Use correction entries for changes.
• Available balance: Separate posted, pending, held, and available funds. Apply holds before an external payout starts.
• Reconciliation: Compare internal journals, provider transactions, settlement files, bank statements, fees, reversals, and customer balances. Create an owned queue for every mismatch.
• Failure recovery: Define what happens after a provider timeout, database timeout, duplicate response, delayed webhook, partial batch, queue retry, or service restart.
• Approval rules: Apply transaction limits and extra approval on the server. Staff overrides require a reason, the right role, an audit record, and a second approver for high-risk changes.

Evidence to keep: concurrent request results, idempotency tests, state diagrams, ledger invariants, reconciliation results, failure simulations, and approval logs.

5. Payment, KYC, and banking integrations

An integration crosses a trust boundary. Validate every incoming event and every outgoing value. A successful HTTP response does not prove a successful financial event.

• Webhook signature: Verify the provider signature against the raw request body with the correct secret and comparison method. Follow the provider’s current instructions, including Paystack’s webhook guidance or the matching guide for your provider.
• Transaction match: Match the provider event to a transaction created by your server. Verify reference, amount, currency, recipient, provider account, product, and expected state.
• Replay control: Store each provider event ID or stable event key before changing value. Process one valid event once.
• Event order: Handle delayed and out-of-order events. A late pending event must never replace a final successful or failed state.
• Pull verification: Query the provider’s trusted API before crediting funds when the provider flow and risk require direct confirmation.
• Callback URLs: Build redirect and callback destinations from a server-side allowlist. Reject a destination supplied by the client outside the approved list.
• KYC result: Map each provider result to a clear internal state. A timeout, malformed response, missing field, or provider error must never create a verified status.
• Identity match: Define the exact match rule for names, date of birth, phone number, document number, selfie result, liveness result, and watchlist result. Send uncertain cases to a named review queue.
• Lookup abuse: Require authentication, rate limits, quotas, monitoring, and cost alerts on BVN, NIN, CAC, account-name, credit, and sanctions lookups.
• Provider permissions: Give each integration key the smallest available scope. Separate test and production keys. Separate keys by service when the provider supports it.
• Secret rotation: Store the current and next secret safely, document the rotation steps, test them, and name the person with authority to rotate during an incident.
• Provider outage: Define safe customer messages, retry rules, queue limits, manual review, reconciliation, and recovery for each provider dependency.

6. Mobile application security

The customer controls the device. Treat the mobile app as an untrusted client and keep authorization, balances, limits, verification state, and transaction rules on the server. Use the OWASP Mobile Application Security Verification Standard to map storage, cryptography, authentication, network, platform, code, resilience, and privacy checks.

• Release build: Remove debug flags, debug menus, test accounts, staging hosts, source maps, verbose logs, sample keys, and development certificates from the production build.
• Secret review: Decompile the release package and search for API keys, private URLs, credentials, signing material, provider secrets, cloud keys, and hidden admin routes.
• Secure storage: Keep refresh tokens and device keys in Android Keystore or iOS Keychain. Keep PINs, OTPs, BVNs, NINs, card data, and passwords out of local storage.
• Network security: Require valid TLS for every connection. Block clear-text traffic. Define certificate pinning from the product’s risk and operational plan. A pinned app needs backup pins and a tested rotation path.
• Deep links: Allowlist schemes, hosts, paths, and parameters. Require server authorization after the app opens. A deep link must never complete a payment or expose a private screen by itself.
• Exported components: Review Android activities, services, receivers, providers, intent filters, iOS URL handlers, app extensions, and universal links. Export only the components required by the product.
• WebViews: Load approved origins. Disable unused bridges and file access. Validate messages between web content and native code. Keep authentication tokens out of URLs.
• Sensitive screens: Protect PIN, OTP, full card, recovery code, and identity screens from screenshots, task-switcher previews, overlays, and clipboard leaks where the platform supports the control.
• Tamper signals: Treat root, jailbreak, emulator, debugger, hook, and repackaging results as risk signals. Enforce high-value rules on the server.
• Update path: Sign releases, protect signing keys, verify over-the-air updates, remove support for unsafe versions, and give users a clear update path.
• Privacy: Request each device permission at the point of use. Collect the data required for the feature. Remove old analytics events that expose customer or transaction data.

7. Customer data and cryptography

Start with a data map. List each sensitive field, why the product collects it, where it enters, where it moves, where it stays, who reads it, and when it is deleted.

• Data inventory: Map identity data, contact data, account data, documents, biometrics, device data, transaction data, support data, staff data, logs, exports, and backups.
• Collection limit: Remove fields that have no current product, legal, security, or operational purpose.
• Transport encryption: Use current TLS across public, partner, internal, administrative, and database connections. Redirect or reject clear-text traffic.
• Storage encryption: Encrypt disks, databases, object storage, backups, and high-risk fields according to the threat model. Keep encryption keys separate from encrypted data.
• Key management: Generate, store, use, rotate, revoke, back up, and destroy keys through a managed Key Management Service or Hardware Security Module process.
• Search and display: Tokenize, hash, or mask sensitive identifiers where full values are unnecessary. Show the minimum digits required for the task.
• Card data: Map every system that stores, processes, or transmits cardholder data. Use the current PCI DSS requirements from the PCI Security Standards Council document library.
• Logs: Remove passwords, PINs, OTPs, access tokens, refresh tokens, authorization headers, full card data, full identity numbers, and raw provider secrets from logs.
• Exports: Require the right role, a business reason, a clear scope, short-lived download access, encryption, an audit record, and a retention deadline.
• Retention: Set a retention period and deletion method for each data class. Apply the rule to primary stores, caches, search indexes, logs, files, analytics tools, and backups.
• Test data: Keep production customer data out of development and test environments. Use generated or approved masked data.
• Backups: Encrypt backups, restrict access, monitor reads, test restoration, and record the last successful recovery test.

8. Cloud infrastructure and software delivery

Production starts with a small public surface and named access. Every open port, broad role, shared credential, and unreviewed deployment expands risk.

• Account separation: Separate production from development and test. Separate high-risk workloads when one shared account gives broad access.
• Public inventory: List every public domain, IP address, load balancer, API gateway, storage endpoint, management panel, and third-party callback.
• Private services: Keep databases, caches, queues, internal APIs, monitoring tools, and management ports on private networks.
• Cloud identity: Use named identities, single sign-on, multi-factor authentication, least privilege, short-lived access, and separate service roles.
• Root access: Protect root and break-glass accounts with hardware-backed authentication, no daily use, monitored login, and tested recovery.
• Secrets: Store production secrets in a managed secret store. Scan source control, build logs, images, packages, mobile apps, and deployment output for leaked values.
• Storage: Block public access by default. Test object permissions and signed links with an unauthenticated browser and a second customer account.
• Container and host baseline: Use maintained base images, remove unused tools, run without root, set resource limits, scan dependencies, and patch supported systems.
• Deployment approval: Protect production branches and environments. Require review, passing security checks, trusted build workers, and a clear rollback path.
• Dependency control: Lock versions, review new packages, scan direct and transitive dependencies, remove unused packages, and set a deadline for critical fixes.
• Build integrity: Limit who changes pipelines, protect signing keys, record build provenance, and prevent untrusted pull requests from reaching deployment secrets.
• Recovery: Define recovery time, recovery point, restore order, required people, provider dependencies, customer communication, and the last tested result.

9. Admin tools and staff access

Admin tools combine customer data and high-value actions. Give each staff member the access required for the job and record every sensitive action.

• Separate entry: Keep admin authentication separate from customer login. Require strong multi-factor authentication for every staff role.
• Network access: Restrict high-risk panels through an approved access proxy, private network, managed device rule, or equivalent control.
• Role design: Separate support, KYC review, compliance, finance, operations, engineering, security, and system administration.
• Maker-checker: Require a second authorized person for high-value balance changes, refunds, payout changes, limit changes, KYC overrides, account recovery, and key operations.
• Fresh authentication: Require recent authentication before exports, impersonation, credential changes, role changes, balance changes, and destructive actions.
• Customer impersonation: Show a clear banner, restrict available actions, record the staff member and reason, notify the right team, and end the session after the task.
• Search and export: Rate-limit broad searches and exports. Mask values in lists. Log the query, filters, result count, reason, and download.
• Audit record: Record actor, role, action, target, old value, new value, reason, approval, time, source, and result for sensitive actions.
• Joiner, mover, leaver: Grant access from an approved role, review it after role changes, and revoke it at the end of employment or contract.
• Access review: Review production, cloud, database, support, provider, source control, analytics, and finance access on a fixed schedule and after staff changes.

10. Logging, fraud monitoring, and incident response

Logs must show what happened, monitoring must find risky behaviour, and the response plan must tell the team what to do next.

• Security events: Record login success and failure, OTP events, recovery, device changes, token reuse, role changes, admin actions, exports, provider failures, transaction state changes, and key operations.
• Transaction signals: Monitor velocity, value, recipient change, new device, account age, location, repeated failure, shared identifiers, unusual hour, rapid cash-out, and linked account behaviour.
• Alert ownership: Give every alert a severity, owner, response time, investigation steps, escalation path, and closure reason.
• Alert test: Trigger each critical alert in a safe environment. Confirm delivery, context, ownership, acknowledgement, and escalation.
• Log protection: Send important logs to a separate controlled system. Restrict deletion and configuration changes. Alert on gaps and disabled sources.
• Clock consistency: Synchronize system clocks and record time zones so API, provider, database, cloud, mobile, and staff events form one timeline.
• Response contacts: Keep current contacts for engineering, security, operations, compliance, leadership, legal support, cloud providers, payment providers, identity providers, and communications.
• Immediate actions: Prepare tested steps to revoke sessions, freeze risky transactions, disable a feature, block a key, rotate a secret, preserve evidence, restore service, and notify required parties.
• Response exercises: Run exercises for account takeover, forged webhook, leaked production key, exposed database, malicious staff action, provider outage, ransomware, and incorrect balance updates.
• Customer support: Give support staff approved steps for reports of unknown devices, missing funds, changed details, suspicious messages, and account takeover.

11. Evidence and final approval

Final approval needs evidence from the release that will reach users. A passing result from an old environment does not approve new code, new infrastructure, or a changed payment flow.

• Scope record: List applications, versions, commits, APIs, roles, providers, cloud accounts, environments, and excluded systems.
• Control record: Give each checklist item a result, owner, test date, evidence link, gap, deadline, and retest result.
• Architecture: Keep current data-flow, trust-boundary, network, identity, payment, webhook, and deployment diagrams.
• Risk acceptance: Name the business owner, exact risk, affected users, affected data or value, reason, temporary control, expiry date, and fix deadline.
• Independent testing: Run a scoped penetration test against the release candidate and its production configuration. Track every confirmed finding through remediation and retest.
• Launch decision: Record who approved the release, which gaps remain, when each gap expires, and which event triggers an immediate review.

Use the result

Turn every failed item into owned work. Fix release blockers first. Group the remaining work by authentication, authorization, transactions, integrations, mobile, data, cloud, admin access, and monitoring. Retest each fix in the release environment. Keep the final evidence pack for engineering review, enterprise due diligence, partner onboarding, internal risk decisions, and regulatory work.

Independent testing checks whether the implementation matches the checklist. Review our penetration testing, API security testing, mobile app penetration testing, and authentication security review services.