Three payments are requested on a Tuesday. The first is to a body shop whose name matches an entry on a sanctions list. The second is the same amount to the same payee on the same feature as a payment eleven days ago. The third is to a medical provider with no tax ID on file. In most claims systems, each of these either goes out — and becomes a problem — or fails with an error the adjuster cannot interpret.
InsightCW does neither. A payment control holds the payment: it exists, it is visible, its reason is on the file, and a named person releases it or leaves it held. This post walks the three cases and shows who sees each hold, who releases it and what the record keeps. The payees and amounts are illustrative.
| Actors | Adjusters (requesters), supervisor, compliance, finance |
|---|---|
| Trigger | A payment requested or issued on any claim |
| Line | Every line; the cyber line adds its own sanctions hold on threat actors |
| Agents involved | Reserving (payment requests at L3 go through the same controls), supervisor (prepares the release decision) |
| Decisions and authority | Releasing a hold (supervisor or compliance, with a reason), then the ordinary payment authority |
| Systems touched | InsightCede and InsightUW receive claim.payment_issued only once money actually moves |
| Outcome | No payment reaches a sanctioned party, no duplicate goes out, every 1099-reportable payee has a W-9 before payment |
| What is measured | Holds by code, time to release, holds released versus left held, duplicates caught, payments voided after issue (should fall) |
Why a hold beats a failure
problem found later"] B -->|"hard error"| D["Adjuster retries,
works around it"] C --> E["Recovery, void,
regulator"] D --> E style C fill:#fdecec,stroke:#e57373 style D fill:#fff4e2,stroke:#f4a03a
A hard failure teaches people to work around the check. A missing check teaches nobody anything until it is too late. A hold puts the decision with the person who should make it, with the reason in front of them.
sanctions, duplicate,
1099"] B -->|"clear"| F["Authority as usual"] B -->|"hold"| C["on_hold with code
and reason; verdict
becomes hold"] C --> D["Up next: payment_hold
for supervisors"] D --> E{"Released with
a reason?"} E -->|"yes"| F E -->|"no"| G["Stays held"] F --> H["Issued: rules run
again at issue"] style C fill:#efeafe,stroke:#7c6cf0 style E fill:#e8f8f4,stroke:#22c1a4,stroke-width:2px
The three controls
| Rule | Fires when | The reason the adjuster sees |
|---|---|---|
PAY_SANCTIONS | The payee is flagged, or their name matches a sanctioned party or vendor | The payee matches a sanctions list (OFAC); compliance must clear it before any money moves |
PAY_DUPLICATE | Same payee, same net amount, same feature within 30 days (issued, cleared or still live) | The same amount went to the same payee on this feature N days ago |
PAY_1099 | The payment is 1099-reportable (or the payee is a vendor, attorney or provider) and there is no tax ID on file | The payment is 1099-reportable and the payee has no tax ID (W-9) on file |
They are rules on the shared engine, type payment_control, editable in the Rules
Studio. They run when a payment is requested and again when it is issued, because the world can
change in between. A rule can also require an approval rather than hold: for example,
asking for one on a payment type even inside the requester's authority.
Who talks to whom
Step by step
The payee's name matches a sanctioned party. The payment is created as on hold with code sanctions. The decision record gets a block hit; the claim's verdict becomes “hold”; the adjuster sees why on the financials zone.
A different entity with a similar name. Compliance releases the hold with a reason. The released code stays released for that payment only; the next payment to the same name is screened again.
The same net amount went to the same payee on the same feature eleven days ago. Held with code duplicate and the number of days in the reason.
It is a genuine duplicate — a second invoice for the same repair. The supervisor leaves it held and the adjuster cancels the request. Nothing went out, so nothing needs recovering.
1099-reportable and no tax ID on file. Held with code tax_1099.
The provider's W-9 arrives; the tax ID is recorded on the party; the supervisor releases the hold with a reason. The payment then goes through authority as any other, and the rules run once more at issue.
Only now does claim.payment_issued reach InsightCede and InsightUW. A void later would emit claim.payment_voided, taken back in the cessions.
What the screens show
What the agents do here
| Agent | What it prepared | What it cites | Who decides |
|---|---|---|---|
| Reserving | A payment request for an agreed, unpaid settlement amount | The settlement and the ledger | Adjuster; at L3 with pull-back |
| Supervisor | The release decision prepared with the hold's code, reason and the payee's history | The hold, the payee party, prior payments | Supervisor or compliance |
An agent is held exactly like a person
When an agent at L3 requests a payment, it calls the same governed tool a person's Accept uses, so the same controls run and the same holds apply. It cannot release a hold, and a payment it requests at L3 opens a pull-back window in which a person can void it.
Edge cases
| What happens | What InsightCW does |
|---|---|
| Two codes on one payment | Both are listed; releasing one leaves the other holding. |
| Legal or vendor spend | An approved legal bill or vendor invoice becomes an expense payment request, so the same controls apply. |
| A cyber extortion payment | CY_SANCTIONS_HOLD holds it if the threat actor matches a sanctions list, on top of the general control. |
| A hold sits too long | The approval-decision clock and Up next make it visible; it never silently expires into a payment. |
The decision record when a payment is held
A hold is a decision event: it writes a run of its own. For the body shop payment at 09:10:
| Section | Hit | Outcome |
|---|---|---|
| Payment holds | PAY_SANCTIONS: the payee matches a sanctions list (OFAC); compliance must clear it | block |
| Authority | Payment inside the requester's authority (applies after release) | pass |
| Event | Payment held with code sanctions | block |
And at 10:30, the release is a decision event too: who released it, the code released and the reason. The two runs together are the audit trail a regulator asks for.
Ask the copilot
| Ask the copilot | Lookups it calls | What the answer covers |
|---|---|---|
| “Why is this payment held?” | reserves_and_payments, decision_record | The code, the reason and who may release it. |
| “Have we paid this payee before on this claim?” | reserves_and_payments, parties_and_approvals | Prior payments to the payee by feature and date, and whether a tax ID is on file. |
Tuning it for your book
- The duplicate window. 30 days on the same payee, amount and feature is the default; widen it if your payees rebill slowly.
- Who releases. Sanctions holds belong to compliance; duplicate and 1099 holds usually to supervisors. Give each the role.
- Require-approval rules. Use them for payment types that always deserve a second pair of eyes, even inside authority.
- The sanctions source. A payee is held when the party is flagged or its name matches a sanctioned party or vendor. Keep the flags current from your screening service.
On the desk
A held payment tells you why. You fix what can be fixed — a W-9 — and a supervisor releases it.
For claims IT
payment_control rules run at request and at issue; holds are on_hold payments with codes; release is audited; payment events fire only when money moves.
For claims leadership
Payments are where claims operations meet regulators. Measure holds by code, time to release and payments voided after issue.
Variations
A settlement payment before the release
The settlement controls stop it: no payment of a settlement until a signed release is on file. It is a different control from the payment rules and it serves the same purpose — money never moves ahead of the paper that justifies it.
A vendor invoice
An approved vendor invoice becomes an expense payment request with the payee type vendor, which makes it 1099-reportable by default. A vendor without a W-9 is held exactly like a provider.
An agent requests the payment
At L3, the reserving agent can request payment of an agreed, unpaid settlement amount. It calls the same governed tool a person's Accept uses, so the same controls run, and the payment opens a pull-back window in which a person can void it. Below L3, the request comes back as prepared work and nothing happens.
Rolling it out
- Screening data: keep sanctioned-party flags current on parties and vendors.
- Tax IDs: backfill W-9s for regular payees before go-live, or the first week will be a week of 1099 holds.
- Release roles: compliance for sanctions, supervisors for the rest.
- Measure: holds by code, time to release and payments voided after issue.
Questions we get asked
Is a hold the same as an approval?
No. A hold parks the payment until a person with the right role releases it with a reason; after release, the ordinary authority check still applies. A rule can also require an approval instead of holding.
Do the controls run again at issue?
Yes. They run at request and again at issue, because a payee's status can change in between.
Can a hold be released by an agent?
No. Releasing a hold is a person's action.
Can an auditor replay what happened?
Yes. Every Analyze, stage action and payment hold writes a run to the decision record, with the hits in order, the rule and facts behind each, and the verdict. Every agent step records its model, tokens, cost and confidence, and a Lense trace when tracing is configured.
What the person still decides
- Whether a match is real. A sanctions hit is a question for compliance, not a model.
- Whether a duplicate is a duplicate. Sometimes two equal payments are correct.
- The release reason, which stays on the file for the auditor.