Ledger app security checklist

• journal_entries and journal_lines are append-only: the application database role has INSERT and SELECT only, a trigger rejects UPDATE/DELETE/TRUNCATE for every role, and corrections are reversing entries linked by reverses_entry_id.
• Balance is enforced by the database, not just by code: a deferred constraint trigger asserts sum of debits equals sum of credits per entry per currency at commit, lines require amount_minor > 0 and matching account currency; the integrity job re-checks continuously.
• Every admin action, limit change, freeze, adjustment and refund writes hash-chained audit_log rows; the chain is verified nightly and a break is a sev-1.
• The product must never imply the operator holds deposits or is a bank/money transmitter: customer funds are held by the licensed partner, UI copy and terms must say so, and no feature may custody funds outside the partner.

• Money is bigint minor units plus currency everywhere, including API payloads (integer strings) and tests; lint/CI rule rejects float, number arithmetic on money fields, and rounding outside a single named allocation function.
• All processor webhooks verify the signature over the raw body with a timestamp tolerance, are stored by unique event id, and only the verified event (not the client redirect) credits a wallet.

• Per-transaction, daily, monthly, max-balance and velocity limits plus a global daily withdrawal ceiling fail closed: if the limit service or counters cannot be read, the money movement is refused. New destinations have a cooling-off hold before the first withdrawal.
• Block and review on: many new counterparties/hour, rapid in-out cycling, deposit then immediate withdrawal to a new destination, mismatched device/IP geography, repeated failed attempts; frozen accounts reject all postings except admin-approved compliance entries.

• KYC documents stay with the verification provider; Forge stores outcome + reference only; names, addresses and bank references are encrypted at column level, masked in logs, and exportable/erasable subject to financial retention law (erasure of retained records means pseudonymise, not delete the ledger).

• KYC / AML / sanctions (applies to holding or moving customer funds): Customer identification, sanctions/PEP screening, transaction monitoring and suspicious-activity reporting are legal duties of the licensed partner and, depending on structure, the operator. Phase 1 caps limits at an unverified tier; verification runs through a provider (phase 2).
• GDPR and financial record retention (applies to EU users): Ledger records must be retained (commonly 5-7 years) which overrides erasure for those records: pseudonymise personal data, keep amounts and references, document the legal basis.
• Audit and SOC 2 posture (applies to B2B or regulated customers): Hash-chained audit log, four-eyes manual adjustments, access reviews and daily reconciliation evidence are the controls auditors ask for first.
• Consumer disclosures (applies to consumer-facing): Fees, FX margins, limits, dispute and refund procedures and statement availability must be disclosed clearly; error-resolution timelines depend on jurisdiction.
• Accessibility: WCAG 2.2 AA for amounts, tables and confirmation flows; never rely on colour alone for debit/credit.

• platform daily withdrawal minor: hard in-code ceiling on total payouts per day; withdrawals refused at 100%, alert at 90%.
• platform daily deposit minor: ceiling on deposited volume per day; new deposit intents refused over the limit.
• per user limits: per-transaction, daily, monthly and max-balance limits per tier; checked inside the posting transaction and fail closed.
• statement pdf per user month: capped generation per user; regenerable on demand within the cap.
• reconciliation api calls day: bounded paginated reads against the processor API per run.

Forge64 gives every app its own Postgres database and runs a quality gate that flags unauthenticated writes and secrets in client code before you see the app. It does not replace your own testing, and it holds no third-party security certification today.

This is a reference design for the category, not a promise that every item is generated today. Built-ins such as email, background jobs, file uploads and search are coming soon, so anything here that needs them is something you add yourself for now.

• Sign in as two different users and try to open each other's records by changing the id in the address.
• Submit each form with an empty value, a very long value and a script tag, and check the result.
• Call each write endpoint without signing in and check that it refuses.

What is the biggest security risk in a ledger app?

journal_entries and journal_lines are append-only: the application database role has INSERT and SELECT only, a trigger rejects UPDATE/DELETE/TRUNCATE for every role, and corrections are reversing entries linked by reverses_entry_id.

Does a ledger app have compliance obligations?

KYC / AML / sanctions, if you have holding or moving customer funds: Customer identification, sanctions/PEP screening, transaction monitoring and suspicious-activity reporting are legal duties of the licensed partner and, depending on structure, the operator. Phase 1 caps limits at an unverified tier; verification runs through a provider (phase 2). This is a starting point, not legal advice.

Will Forge64 certify my app as secure?

No. Forge64 holds no third-party security certification today and does not certify apps. The checklist is a way to test your own app.

• How to build a ledger app
• Ledger app architecture
• Example prompt for a ledger app
• Ledger app scaling checklist
• Often combined: marketplace
• Often combined: SaaS dashboard
• All app types