Insurance: P&C, Life & Annuity · Java SDK
Your claims agent proposes a settlement. Before the payment call runs, the Java SDK sends the claim facts to your carrier rules. The result tells your code to pay, hand the claim to an adjuster, or stop.
Run each of these in the claims simulator. Run claims simulator
When: A routine auto collision claim, well inside the limit.
Your code: The payment runs, and the record keeps the claim facts next to the rule that allowed it.
Who picks it up: The Business Owner sees settlement volume. Auditors read the record inside an engagement.
When: A third claim on the same policy in 12 months.
Your code: The settlement waits. The adjuster sees the claim facts and your brief.
Who picks it up: The adjuster with that authority, in the VeriProof Inbox, by email, or in Slack or Microsoft Teams, with reminders and escalation.
When: The fraud score is above the carrier’s limit.
Your code: The status is BLOCKED, and no payment is issued.
Who picks it up: The Governance Engineer sees which rule stopped the payout.
The claims simulator sends these seven fields. Your fraud model and policy system already produce most of them.
| Fact | What it holds |
|---|---|
claim_type | auto_collision, water_damage, theft, or minor_injury. |
claim_amount_usd | The proposed settlement amount. |
coverage_limit_usd | The limit on the policy that covers this claim. |
policy_in_force | True when the policy was active on the date of loss. |
fraud_signal_score | The score your fraud model returned for this claim. |
prior_claims_12mo | Claims filed on this policy in the last 12 months. |
injury_involved | True when someone was hurt. |
The review options give the adjuster a short brief if a rule asks for one. The profile names a review form set up in the portal.
Java · com.veriproof:veriproof-sdk-core
import com.veriproof.sdk.GovernOptions;
import com.veriproof.sdk.GovernReviewOptions;
import java.util.Map;
var result = veriproof.govern(
"claim.settle",
settlement,
context -> payments.issue(context.input(), context.idempotencyKey()),
GovernOptions.builder()
.facts(Map.of(
"claim_type", claim.type(),
"claim_amount_usd", settlement.amountUsd(),
"coverage_limit_usd", policy.coverageLimitUsd(),
"policy_in_force", policy.inForceOn(claim.lossDate()),
"fraud_signal_score", fraudModel.score(claim),
"prior_claims_12mo", history.claimsInLastYear(policy),
"injury_involved", claim.injuryInvolved()))
.review(new GovernReviewOptions(
"claim-settlement-review",
"The claims agent reviewed the photos and repair estimate.",
"Pay the settlement amount shown.",
null))
.build());
if (!result.completed()) {
reviews.saveIfRequired(result);
log.info("{} {} {}", result.status(), result.reasonCode(), result.message());
}payments.issue receives the idempotency key, so your payment system can reject a duplicate. If execution() reports an uncertain completion, check the payment before any retry.
Why Java here: Most policy administration and claims platforms run on the JVM, so the check wraps the payment call where it already lives.
Your fraud model produces fraud_signal_score. The rule decides what score is too high. When the threshold moves, that’s a rule change you can try in Shadow, not a model redeploy.
Developer fix request
If compliance adds a rule on whether the repair shop is in your network, and your agent doesn’t send that yet, the Developer gets a fix request naming the field.
Changing the rule
Moving the fraud score limit is a rule change. Try it in Shadow against live claims, then send it for approval. An engineer’s change to a production agent needs an administrator or compliance officer.
For your business owner
The insurance page explains what the agent can take on and how its decisions are defended.
Read the insurance business caseDocs
Install com.veriproof:veriproof-sdk-core, configure the key, and look up industry values for Insurance: P&C, Life & Annuity.
The claims simulator runs the same rule check on sample claims. Open the record afterward and match each field to the table above.