Decisions in minutes · auditable · explainable Straight-through processing as the default AI platform for insurance LGPD-compliant Decisions in minutes · auditable · explainable Straight-through processing as the default
Back to Insights & News
· Article

Insurance risk and fraud engine with an AI layer

How an external AI layer scores risk and flags fraud inside underwriting, calibrated to appetite and manual, with a full audit trail and no core migration. Talk to WIR.

What a risk and fraud engine with an AI layer means

An insurance risk and fraud engine with AI is an external intelligence layer that scores each submission and flags suspected fraud as a stage of the underwriting (subscrição) journey, calibrated to the insurer's risk appetite and underwriting manual. It reads the quote request, weighs many factors with a Machine Learning model, and returns a risk score, a probability, and a recommended automated decision, while the insurer's core systems stay in place. This is for an underwriting lead, a product or innovation head, or a broker (corretor) team that wants faster and more consistent risk selection without a core migration.

The engine sits between submission intake and the underwriter's final call, and it never owns the policy. Policy administration, premium (prêmio) booking, and the official record continue to run on the systems the insurer already operates. WIR is the AI layer for insurance in Brazil, on top of the systems the insurer already runs, never in their place. The honest claim is sharper here than a sales promise. A calibrated model raises detection rates, consistency, and speed, but no engine eliminates fraud, and adverse or high-exposure cases stay with a human. Every output is explainable and returns a full audit trail, with data encrypted at every step and handled under LGPD.

How risk scoring and fraud triage work

The stage runs as a sequence rather than a single black-box step. First, the engine takes in the quote request and supporting documents from the broker channel or the insurer portal, across the formats the insurer already uses such as e-mail, attachments, or an API. Next, it reads those documents and extracts the relevant fields automatically, then enriches the case by cross-referencing external sources. After that, a multi-factor ML model weighs risk factors and fraud indicators together, calibrated to the underwriting manual and the risk appetite for that line of business (ramo). The model then produces a risk score, a probability, and a recommended decision such as auto-approve, refer to an underwriter, decline, or flag for fraud review. Finally, clean low-risk cases can be auto-decided to free underwriter time, while ambiguous or high-exposure cases are routed to a human with the supporting evidence attached.

The decisive word is calibrated. A generic fraud model is not the same as one tuned to a specific insurer's appetite, manual rules, and historical loss patterns per ramo. Calibration lets the same engine stay conservative on a line where the insurer wants to grow cautiously and more permissive where it wants volume. The engine encodes the manual, it does not overrule it. The model is multi-factor by design because single-signal rules, like a static blacklist or a hard threshold, are brittle and easy to game. Combining many weaker signals into one score raises detection on novel patterns that no single rule would catch.

The lift over manual scoring comes from data the underwriter cannot check by hand at quote speed. The engine validates CNPJ and CPF status to confirm the proposing entity exists, is active, and matches the declared activity, since a recently opened or irregular CNPJ on a high-value cover is a classic flag. It reads broker history to surface submission quality, historical loss ratio, and clusters of suspicious cases concentrated in one channel. It checks exposure and accumulation to see whether the risk overlaps existing cover on the same insured, address, or fleet. It uses credit and financial behavior as one factor among many, never as a sole decision basis, and it cross-checks the declarations against the extracted document data to surface contradictions. This is also a distribution advantage, because brokers choose insurers partly on response speed, and a consistent, defensible decision in seconds rather than days improves conversion while keeping risk selection disciplined.

How to deploy the risk engine as an external layer

Deployment is an integration, not a system migration, and the insurer's IT team does not have to run a rebuild. The engine connects on top of the existing core through the channels already in use, so policy administration and premium booking continue without interruption. The work is scoping the lines and use cases, integrating with the current systems, calibrating the model to the underwriting manual and risk appetite, testing against real historical submissions, going live, and then operating continuously. WIR structures this as a one-time setup that runs 3 to 12 months, with a fixed price, a clear scope, and KPIs agreed before the work starts, followed by continuous operation after go-live with a billing model adjusted per client.

Calibration is the part that determines value, and it happens with the insurer, not in isolation. The model is tuned to the manual rules, the appetite per ramo, and the historical loss patterns the insurer has already seen, so the outputs reflect that insurer's own selection policy rather than a benchmark borrowed from someone else. Testing against past cases shows where the score agrees with prior underwriter decisions and where it diverges, which is exactly the conversation that builds trust before any case is auto-decided. Because the layer is external, the insurer keeps full control of the core and can widen the lines covered over time without a second migration.

Governance, explainability, and LGPD

An automated underwriting and fraud decision in Brazil cannot be a black box, and two requirements drive the design. Each risk score and recommendation carries the factors that drove it, which signals pushed the score up and which pushed it down, so an underwriter can review, override, and justify the outcome. This is operationally necessary, because underwriters will not trust an unexplained score, and it is legally relevant. Alongside it, every decision is reconstructable through a complete audit trail that records what data was read, which model version ran, what the output was, and who reviewed or overrode it. That trail supports internal governance and SUSEP supervision of P&C conduct, and it protects the insurer if a declined or flagged case is later contested.

On data protection, the LGPD (Lei Geral de Proteção de Dados, Lei 13.709/2018) is directly relevant. Article 20 gives the data subject the right to request review of decisions taken solely on the basis of automated processing of personal data that affect their interests, including decisions intended to define profiles. In practice this reinforces three things for a risk and fraud engine. Keep a human-review path for adverse automated outcomes, log the basis of each decision, and be able to provide information about the criteria used. An external AI layer that produces explainable, logged decisions and routes adverse or ambiguous cases to a human is aligned with this framework, with personal and credit data used only as part of a transparent, multi-factor process, encrypted at every step. You can read the full LGPD text on automated decisions at Planalto and reference the ANPD, the national data protection authority.

How WIR operates the risk and fraud engine

WIR is the AI layer for insurance in Brazil, an external platform that automates the quotation and underwriting journey on top of the insurer's existing systems, calibrated to that insurer's risk appetite and underwriting manual. The risk and fraud engine is the fourth stage of a six-stage flow that moves from multichannel intake and automatic validation, to intelligent document reading, to broker enrichment and context, to the multi-factor ML risk and fraud engine, to dynamic risk-adjusted pricing, and finally to decision and prioritization. At decision time the platform issues a quote, an automatic decline, or an escalation to a human, always with an explanation, writes the result back to the policy core, and returns the audit trail with a visible SLA and an underwriter queue.

Two modules carry this in production. Underwriter Intelligence automates the quotation journey per the insurer's risk policy, with real-time ML scoring calibrated to appetite, automatic routing by appetite and exposure, and predictive conversion analysis by product, risk, and broker, so underwriters spend their time on ambiguous and high-value cases rather than cross-referencing. Smart Sales adds distribution intelligence, mapping the portfolio by client and product, scoring next-best-action, and running multi-channel campaigns with an attribution trail. Real-time dashboards give a proactive view of in-flight deals and pipeline.

The context behind this is a market that grows double digits per year while company structure does not keep pace. Underwriters spend 40% of their time on administrative tasks, according to Deloitte, and 70% of insurers do not execute innovation because of IT limitations, according to BCG. 60%+ of brokers choose an insurer by response speed, according to Capgemini, and corporates lose 20% to 30% of their time organizing unstructured data, according to Gartner. WIR was founded in 2025, built with Mahway and Avante, and its first POC is in execution with a global insurer in the Transport line. To map how your insurer could score risk and triage fraud with a calibrated AI layer, talk to WIR.

Frequently asked questions

How is the risk score calibrated to the underwriting manual?

The score is tuned to the insurer's own manual rules, risk appetite per line of business, and historical loss patterns, so outputs reflect that insurer's selection policy. WIR calibrates the multi-factor Machine Learning model with the insurer during setup, then tests it against real historical submissions to show where it agrees with prior underwriter decisions and where it diverges. The engine encodes the manual, it does not overrule it, staying conservative or permissive per ramo as the appetite dictates.

Which external sources does the engine cross-reference?

The engine validates CNPJ and CPF status, reads broker history, checks exposure and accumulation, and uses credit and financial behavior as one factor among many. It cross-checks the declarations against the extracted document data to surface contradictions, like a recently opened CNPJ on a high-value cover. Credit data is never a sole decision basis. This lift comes from data an underwriter cannot verify by hand at quote speed, combined into one calibrated risk score.

Is every risk and fraud decision explainable and auditable?

Yes. Each risk score and recommendation carries the factors that drove it, which signals pushed the score up and which pushed it down, so an underwriter can review, override, and justify the outcome. Every decision is reconstructable through a complete audit trail recording what data was read, which model version ran, the output, and who reviewed it. That trail supports internal governance and SUSEP supervision, and aligns with LGPD Article 20 on automated decisions.

Does the risk engine replace the underwriting team?

No. The engine augments underwriters, it never replaces the team. Clean low-risk cases can be auto-decided to free underwriter time, while ambiguous or high-exposure cases route to a human with supporting evidence attached. A calibrated model raises detection, consistency, and speed, but no engine eliminates fraud and adverse cases stay with a person. WIR's Underwriter Intelligence module lets underwriters spend their time on ambiguous and high-value cases rather than cross-referencing data.

How long until the engine goes into production?

WIR structures deployment as a one-time setup that runs 3 to 12 months, with a fixed price, clear scope, and KPIs agreed before the work starts. The work is scoping lines and use cases, integrating with current systems, calibrating to the manual and appetite, testing against historical submissions, then going live. This is an integration on top of the existing core, not a system migration, so policy administration and premium booking continue without interruption.