Claims system security checklist

• Brokers see only policies in their producer hierarchy; adjusters see claims assigned to their team; payment approval limits are enforced in the database transaction, not only in the UI.

• Personal identifiers are field-encrypted with blind indexes for matching; they are masked in lists and logs and decrypted only for authorised roles with an audit entry.

• FNOL and quote endpoints are rate limited, validate document types and sizes, and cannot enumerate policy numbers; error messages do not reveal whether a policy exists.

• Evidence uploads are type- and size-validated, scanned, stored under non-guessable keys and served only by signed URLs.

• Premium webhooks are signature verified and idempotent; claim payments need a different approver than the creator and cannot exceed coverage limits.

• Policy versions, reserves and payments are append only; corrections are new rows with reason and actor, and the audit chain is verified nightly.

• Insurance regulation and licensing (applies to regulated carriers): Rate filing, producer licensing, claims handling timelines and solvency reporting vary by jurisdiction; the app records dates and approvals but does not make an entity compliant.
• Privacy and sensitive data (applies to personal data): Claims contain health, financial and identity data subject to GDPR, GLBA or local equivalents; apply minimisation, encryption, access logging and retention rules.
• Anti-fraud and sanctions screening: Sanctions and AML checks use external lists; phase 1 stores results from a screening provider and does not decide on sanctions itself.
• Records retention: Policy and claim records are retained for statutory periods; retention class per document type with legal hold.

• scanning per org day: daily scan budget per organisation; uploads queue as unscanned and stay unavailable.
• export rows per org day: daily export row ceiling per tenant, fails closed.
• storage gb per org: per-tenant quota for claim evidence.

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 background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it 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 claims system?

Brokers see only policies in their producer hierarchy; adjusters see claims assigned to their team; payment approval limits are enforced in the database transaction, not only in the UI.

Does a claims system have compliance obligations?

Insurance regulation and licensing, if you have regulated carriers: Rate filing, producer licensing, claims handling timelines and solvency reporting vary by jurisdiction; the app records dates and approvals but does not make an entity compliant. 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 claims system
• Claims system architecture
• Example prompt for a claims system
• Claims system scaling checklist
• Often combined: accounting system
• Often combined: approval workflow app
• All app types