Proposal received: life branch I, customer Jones M. 72 years. Target market pass (over-50 balanced). Vulnerable customer over-65: additional disclosures required (enhanced pre-contractual information + express consent). POG registry: target market exception documented. Proposal suspended.
AGENT · IDD GATE
Life and health policy proposals pass the IDD check before submission.
IDD Gate verifies every life and health policy proposal before submission to the customer: mandatory IDD (Insurance Distribution Directive) disclosures, target market check, vulnerable customer check, POG registry update. Outcome traced for regulatory audit. The intermediary proceeds only with compliant proposals.
IDD Gate at work.
Adding the required disclosures. Confirming full package submission.
Proposal updated: disclosures integrated. Check passed. Event recorded in POG registry and audit registry.
Why it exists.
The Insurance Distribution Directive imposes precise requirements on insurers and intermediaries distributing life and health policies: target market verification for every product distributed, management of vulnerable customer categories with dedicated disclosures, POG registry update for every transaction. National supervisory frameworks add further requirements in each EU jurisdiction. Manual pre-screening of every proposal is slow and error-prone.
How it works pre-submission.
IDD Gate activates before proposal submission. It extracts product and customer data, applies the IDD rules configured by the compliance team, and classifies the outcome: silent pass for compliant proposals, flag with alternatives for borderline cases, block with escalation to the compliance officer for significant violations. The record of every decision is available for regulatory audit.
The final decision stays with the intermediary.
For clearly non-compliant proposals, block with escalation. For borderline, flag without blocking. For compliant, silent pass. The final decision on submission always stays with the intermediary or compliance officer, following company procedures.
The teams that manage distribution compliance in a structured way.
RUI intermediary or adviser
Receives real-time feedback on the proposal before sending it to the customer. Recovers the time spent on manual verification, reduces disclosure errors, and avoids downstream compliance blocks.
Target market POG COMPLIANT
Vulnerable customer VERIFY
Pre-contractual info COMPLIANT
POG registry UPDATED
1 verification required before send
Compliance officer
Has an inspectable trace of every IDD decision — product, customer, rules applied, outcome — for regulatory audit under IDD and national supervisory frameworks (IVASS, BaFin, AMF depending on jurisdiction).
Claim type Auto liability
Severity Medium
Adjuster Dr. Ferrari · Northeast
Initial reserve € 4,200
Routed ✓
Distribution network manager
Sees in aggregate the IDD error patterns across the network: which products generate the most flags, which customer categories most often require additional disclosures. Network training is based on data, not impressions.
fnol.receive 09:14:22 ALLOW
triage.classify 09:14:25 ALLOW
idd.check 09:14:31 WARN
liquidation.propose 09:15:02 ALLOW
SELECT * FROM audit_log WHERE claim_id = '2024-0847'
A borderline proposal handled in minutes without blockages.
Target market, vulnerable customer, POG registry.
An RUI intermediary prepares a life branch I policy proposal for a customer over seventy. The proposal arrives in the agent's work channel at the point of drafting. IDD Gate runs three checks in sequence. Target market check: life branch I product designed for the over-50 segment with a balanced profile. Customer over seventy: within target. Pass.
Vulnerable customer: additional disclosures required.
Vulnerable customer check: customer over sixty-five, vulnerable category confirmed. The product requires additional disclosures — enhanced pre-contractual information and an express consent declaration on product risk. Flag with the exact list of missing disclosures. POG registry update: the transaction requires tracing the target market exception with documentation.
The intermediary integrates. The proposal goes out compliant.
The intermediary receives the flag on their work channel, adds the indicated disclosures, and confirms. The proposal goes out with the complete package. The event — proposal, rules applied, flags generated, adviser actions, final outcome — stays in the POG registry and the runtime audit registry.
Declarative rules from the company's IDD compliance team.
The rules of IDD Gate are declarative. The company's IDD compliance team defines in a readable format the target market rules for each product (target segment, documented exceptions), the applicable vulnerable customer categories (over-65, low income, declared financial vulnerability), and the additional disclosures required for each category. The rules live in the customer's repository, versioned. Integration with the insurance management system and the POG registry is built during delivery via a dedicated adapter.
- Language
- TypeScript (Node.js)
- LLM model
- customer's choice: Anthropic, OpenAI, Mistral, open source models hosted internally, AWS Bedrock for a private model
- Built-in controls used
- pii-detector, topic-guardrail, tool-param-validator
- Native delivery channels
- Slack, Telegram, WhatsApp, OpenAI-compatible HTTP
- Insurance management system integration
- dedicated adapter built during delivery by the Exelab team
- POG registry integration
- dedicated adapter built during delivery by the Exelab team
- IDD rules
- declarative, versioned, written by the company's compliance team
- Memory
- persistent per instance, pgvector + PostgreSQL FTS
- Registry
- immutable, queryable with a standard SQL client (regulatory audit inspectable)
How IDD Gate works in detail.
For clearly non-compliant proposals (product outside target market without documented justification, mandatory disclosures missing), IDD Gate blocks with escalation to the compliance officer. For borderline proposals, it flags the additional disclosures required to the intermediary without blocking. For compliant proposals, silent pass. The final decision on submission always stays with the intermediary or compliance officer, following company procedures.
The rules are declarative in the customer's repository. When the national supervisor publishes a regulatory update (new regulation, interpretive circular), the company's compliance team updates the declarative file, tests it in the development environment, and promotes it to production. The update cycle stays entirely inside the company, with no dependency on an external vendor for every regulatory change.
The standard configuration is optimized for life and health because IDD imposes stricter requirements on these branches. Extension to other branches (liability, property) is possible by adding specific declarative rules. Coverage of priority branches is defined during discovery with the company's compliance team.
The typical pattern is 12-18 weeks. Discovery and mapping of life and health products in distribution two weeks, IDD rule and vulnerable customer category configuration three to four weeks, management system and POG registry integration three weeks, testing with real proposals and hand-off to the compliance officer three weeks. Duration depends on the variety of products and the structure of the customer's POG registry.
From a 30-minute conversation to the squad in production.
A 30-45 minute conversation to understand how IDD Gate would configure to the customer's case. Insurance management system, life and health products in distribution, priority vulnerable customer categories under the applicable supervisory framework.