Claims system architecture
Claims system architecture: the decisions that matter
The architecture of a claims system comes down to 3 choices: coverage checks read the policy version in force on the loss date, authority limits enforced inside the write transaction and table-driven rating with reproducible inputs. Each is explained below with the alternatives that were rejected and what you accept by choosing it.
Last checked
Coverage checks read the policy version in force on the loss date
Situation: Endorsements change terms mid-term; a claim must be judged under the terms that applied at loss.
Choice: Immutable policy_versions with effective dates; claim coverage stores the version id it was evaluated against.
- Rejected: Mutate the policy row: loses history.
- Rejected: Snapshot only at bind: misses endorsements.
- Consequence: Queries need an effective-date predicate.
- Consequence: Disputes can be reproduced exactly.
Authority limits enforced inside the write transaction
Situation: UI-only limits can be bypassed by API calls.
Choice: Approval rules are data; the payment and reserve writes evaluate them in the same transaction and reject otherwise.
- Rejected: Client-side limits: bypassable.
- Rejected: Manual review only: does not scale.
- Consequence: Rules need tests per band.
- Consequence: Limit changes are audited configuration changes.
Table-driven rating with reproducible inputs
Situation: Premiums must be explainable to customers and regulators.
Choice: Rating factors live in versioned tables; each quote stores inputs, versions and results.
- Rejected: Rating in code: opaque and slow to change.
- Rejected: External rating service: cost and latency.
- Consequence: Publishing a table is a controlled, audited action.
- Consequence: Complex rating logic may need a phase-2 rules engine.
How the data is indexed
Indexes are chosen from the questions the app asks most often. Each line below names a table and the question its main index answers.
- products: unique (org_id, code) — product code per carrier.
- rating_tables: unique (product_id, version) — immutable version numbers.
- policies: unique (org_id, number) — policy number unique.
- policy_versions: unique (policy_id, version) — version history.
- parties: (org_id, blind_index) — duplicate detection without decrypting.
- claims: unique (org_id, number) — claim number unique.
- claim_reserves: (claim_id, created_at) — reserve history.
- claim_payments: unique (claim_id, idempotency_key) — a retried payment cannot double pay.
What Forge64 provides underneath
Forge64 matches your description to one of 25 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.
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.
FAQ
- What is the most important architecture decision for a claims system?
- Coverage checks read the policy version in force on the loss date. Immutable policy_versions with effective dates; claim coverage stores the version id it was evaluated against.
- Do I have to make these decisions myself?
- No. Forge AI plans them from your description and writes the decisions into the project as architecture records you can read and change.
- What do the alternatives cost me?
- For example, for "Authority limits enforced inside the write transaction": Client-side limits: bypassable. Manual review only: does not scale.
Build your app with Forge64
One prompt to a running app with auth, database, hosting and payments. Start free, no credit card required.
Start building for free