Can SynapCores generate ECOA adverse-action reason codes automatically?

Yes. Because the underwriting model runs in the database, every decision carries its feature-importance breakdown. When a decision is adverse, the top contributing factors become reason codes on the notice — reconstructable from the immutable decision record rather than reverse-engineered later. That is the ECOA / Regulation B adverse-action requirement, and it also satisfies the explainability expectations under Texas TRAIGA, Colorado bias-testing rules, and EU AI Act high-risk classification.

How does it support disparate-impact and fairness testing?

The model, the training data, the scores, and the outcomes live in the same engine, so fairness metrics across protected classes are SQL queries over the decision record — not an offline audit you assemble by hand. You can measure disparate impact continuously and keep the evidence in a tamper-evident table for the NAIC pilot, Colorado, and state DOI examinations.

Does policyholder data leave our environment?

No. SynapCores is self-hosted with local inference — underwriting, claims triage, and generation run inside your environment. PII and claims data never transit a third-party AI API, which removes the vendor-data-processing exposure a cloud LLM would create.

Insurance compliance, with the paper trail built in

Underwrite and adjudicate claims with adverse-action reason codes, feature-level model lineage, and immutable decision records — the ECOA / TRAIGA / Colorado / EU-AI-Act evidence generated automatically. Self-hosted, so policyholder data never leaves.

Book a demo See it run Self-host the free CE

Technical champion evaluating? Self-host it, then bring us to your compliance and actuarial leads.

The pain we built this for

If you own underwriting or claims governance, the regulators arrived before the tooling did: “We use models to price and adjudicate, but every adverse decision needs a reason code, a model-lineage record, and a disparate-impact test — and today that evidence is assembled by hand, after the fact, for each exam.”

ECOA / Reg B require specific adverse-action reason codes — but the model that made the decision lives outside the record, so codes get reverse-engineered.
Texas TRAIGA, Colorado bias-testing, the NAIC AI pilot, and the EU AI Act (insurance = high-risk) all now demand explainability, model lineage, and fairness evidence.
Disparate-impact testing is an offline project every quarter instead of a continuous query over the decisions you already made.
Claims fraud signals live in a separate model; the audit lives in a separate wiki; the decision lives in the PAS — three sources, no single defensible trail.
And none of the policyholder data can go to a third-party AI API.

See it — a decision that explains itself

Score in-database, turn feature importances into reason codes, and write it all to a tamper-evident record — a few statements.

-- The immutable decision record: reason codes + model version, tamper-evident.
CREATE IMMUTABLE TABLE uw_decisions (
  application_id TEXT,
  model_version  TEXT,
  score          DOUBLE,
  decision       TEXT,          -- approve / decline / refer
  reason_codes   JSONB,         -- ECOA / Reg B top factors
  decided_by     TEXT           -- model proposal + human approver
) WITH (ENCRYPTION = 'AES256GCM');

-- Score in-database; the feature importances become the reason codes.
SELECT AUTOML.PREDICT('uw_risk_model', :features) AS score,
       AUTOML.EXPLAIN('uw_risk_model', :features) AS reason_codes;

-- For the examiner: prove the decision log was never rewritten.
VERIFY TABLE uw_decisions;

Six capabilities. One self-hosted stack.

Explainable models, automatic reason codes, immutable records, fairness testing, claims triage — over one store, no stitching.

Explainable underwriting in the database

Train and score risk models in SQL and get a feature-importance breakdown with every decision — the model runs where the data is, so explainability is a property of the decision, not an afterthought.

AutoML · feature importance · SQL

Automatic adverse-action reason codes

When a decision is adverse, the top contributing factors become the ECOA / Reg B reason codes on the notice — generated from the decision record, not reconstructed weeks later.

GENERATE · decision lineage

Immutable decision records

Every underwriting and claims decision — inputs, model version, score, reason codes, human override — writes to a hash-chained immutable table. VERIFY TABLE proves it was never altered for the examiner.

CREATE IMMUTABLE TABLE · VERIFY TABLE

Disparate-impact & fairness testing

Measure outcomes across protected classes as SQL over the decision record — continuous fairness metrics with the evidence kept for NAIC, Colorado, and DOI review.

SQL analytics · decision record

Claims triage & fraud signals

An agent triages claims, retrieves similar prior claims by narrative, and flags fraud signals with in-database anomaly models — grounded and auditable, not a black box score.

CREATE AGENT · vector · anomaly ML

Human-in-the-loop by default

Agents propose; adjusters and underwriters approve. allow_writes=FALSE keeps automation advisory where regulation requires a human decision-maker.

allow_writes=FALSE · guardrails

The objections a compliance lead raises first

Data residency & PII

Fully self-hosted with local inference. Policyholder PII and claims data never transit a third-party AI API — one environment, one review.

Regulatory defensibility

Every decision is reconstructable from a tamper-evident record with reason codes and model version — the paper trail ECOA, TRAIGA, Colorado, NAIC, and the EU AI Act expect.

Explainability, not black box

Models run in-database with feature importance on every decision. There is no separate model server to interrogate — the explanation ships with the score.

Fits your policy admin system

Sits beside Guidewire, Duck Creek, or your custom PAS. Ingests via API, writes decisions and audit back. It adds the governed brain; your PAS stays source of truth.

Run it yourself — the insurance recipe library

Every claim on this page is a runnable recipe — decision traceability, claims triage, fraud detection, grounded generation. Certified against the latest release.

Adverse-action decision records

Reason codes + model lineage, tamper-evident

Disparate-impact testing

The four-fifths rule in one SQL query

Similar prior claims by narrative

Triage + fraud signal by meaning

Prove a decision was never altered

Hash-chained decision lineage in SQL

Claim-fraud detection (AutoML)

In-database fraud scoring

Browse the full recipe library →

Every recipe is runnable, certified on the latest release

Why one engine beats a stitched pipeline

The model, the score, the reason codes, and the audit share one store — the adverse-action notice is generated from the same record the examiner reviews.
Fairness testing is a query over decisions you already made, not a quarterly offline project.
No policyholder data crossing a boundary to a cloud model — one deployment, one security review.

5-email course · free

Ship an agent with persistent memory in 5 emails

A 5-email course where you build a real agent with persistent memory — one runnable SQL recipe per email, no LangChain, no Pinecone, no Redis. Lesson 1 hits your inbox the second you sign up. After that: a new recipe every Monday. No spam.

Free forever. We'll never share your email.

Decisions that defend themselves

Reason codes on every adverse action, model lineage on every score, an immutable record for every exam — self-hosted. Book a walkthrough on your own book, or self-host the free CE.

Book a demo Self-host the free CE Star on GitHub