How to build a claims system with AI

These are the parts a claims system needs before it is useful. Each one is something the plan covers.

• Carrier, agency and branch tenancy: Separate carriers, MGAs, brokers and their branches with scoped visibility.
• Underwriter, adjuster and broker roles: Different people may quote, bind, reserve or pay.
• Rating tables and policy versions: Reproduce what premium and terms applied on any date.
• Authority-limit approvals: Large reserves, payments and exceptions need a more senior approver.
• Four-eyes on payments: Prevent one person from creating and releasing a claim payment.
• Regulator-grade audit trail: Show who changed coverage decisions, reserves and payments and why.
• Claim evidence and documents: Store photos, estimates, police reports and policy documents.
• Quote and rating engine: Compute premiums from factors in data, not code.
• Claim intake and handling: Capture a loss, check coverage, and run the claim to closure.

• Renewals and diary reminders: Notify before renewals and when claim diaries are due.
• Fraud and anomaly flags: Surface suspicious claims for human review.

Each table below becomes part of the Postgres database that belongs to your app.

• products: forms and rating tables hang off the product by effective dates.
• rating_tables: rows never edited after publish; a new version supersedes.
• policies: status: quote|bound|in_force|lapsed|cancelled|expired.
• policy_versions: kind: new|endorsement|renewal|cancellation; insert only; coverage checks read the version in force on the loss date.
• parties: personal fields encrypted at field level; blind index is an HMAC of normalised identifiers.
• claims: status: reported|coverage_review|open|reserved|settled|denied|closed|reopened; coverage_result recorded with the policy version used.
• claim_reserves: append only; current reserve is the latest row per component; large changes pass the approval chain.
• claim_payments: check (approved_by is null or approved_by <> created_by); payment total cannot exceed the limit of the coverage.
• premium_invoices: status: scheduled|due|paid|overdue|written_off.

• No automated claim denial or payment without a human decision.
• No actuarial pricing models in phase 1; rating is table driven.
• No reinsurance accounting in phase 1.
• No regulated filings submitted from the app.
• No clinical or medical assessment features.
• Partner and registry integrations: plan for it, build it later.

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.

What does a claims system need first?

Carrier, agency and branch tenancy, underwriter, adjuster and broker roles, rating tables and policy versions, authority-limit approvals, four-eyes on payments and regulator-grade audit trail. The plan for a claims system covers all of these before it generates code.

What should I leave out of the first version of a claims system?

No automated claim denial or payment without a human decision. No actuarial pricing models in phase 1; rating is table driven. No reinsurance accounting in phase 1.

Which products define the claims system category?

Well-known examples include Guidewire, Duck Creek, Socotra, Insurity and Lemonade. Use them to decide which features your users expect, then describe your own version.

• Claims system architecture
• Example prompt for a claims system
• Claims system security checklist
• Claims system scaling checklist
• Often combined: accounting system
• Often combined: approval workflow app
• All app types