Find Cross-Carrier Fraud Rings
Before Claims Clear
Each carrier sees only its own slice of a claimant's history. Tilores gives you the full picture — real-time identity resolution across heterogeneous carrier records, queried through a single GraphQL API, deployed inside your own AWS account.
One Person. Five Claims. Four Carriers. One API Call.
A single GraphQL call on a resolved entity turns five separate carrier records into an unmistakable fraud pattern — no joins, no batch jobs, no downstream analytics required.
{
entity(input: { id: "<TANYA_ENTITY_ID>" }) {
entity {
id
recordInsights {
sourceCarriers: frequencyDistribution(
field: "carrier"
) { value frequency percentage }
providers: frequencyDistribution(
field: "providerNPI"
) { value frequency percentage }
attorneys: frequencyDistribution(
field: "attorneyBarNumber"
) { value frequency percentage }
firstClaim: sort(criteria: [{
field: "dateOfLoss", direction: ASC
}]) { first { dateOfLoss lossCause } }
lastClaim: sort(criteria: [{
field: "dateOfLoss", direction: DESC
}]) { first { dateOfLoss lossCause } }
totalExposure: sum(field: "reserveAmount")
}
}
}
} // response.json · 5 records resolved { "recordInsights": { "sourceCarriers": [ { "value": "PROGRESSIVE", "percentage": 20.0 }, { "value": "STATE_FARM", "percentage": 20.0 }, { "value": "GEICO", "percentage": 20.0 }, { "value": "ALLSTATE", "percentage": 40.0 } ], "providers": [{ "value": "1417922018", "frequency": 5, "percentage": 100.0 // every claim, every carrier }], "attorneys": [{ "value": "088421", "frequency": 5, "percentage": 100.0 // same attorney always }], "firstClaim": { "first": { "dateOfLoss": "2025-02-14", "lossCause": "REAR_END" }}, "lastClaim": { "first": { "dateOfLoss": "2025-08-22", "lossCause": "REAR_END" }}, "totalExposure": 102950.00 // one person, 7 months } }
One Search Anchor. Eleven People.
$657K.
Search by the shared provider NPI. One call returns the entire fraud ring — 11 claimants, 30 cross-carrier records, $657K combined exposure. Every entity was invisible to every individual carrier.
{
search(input: {
parameters: {
providerNPI: "1417922018"
}
}) {
entities {
id
records {
firstName
lastName
carrier
}
recordInsights {
carriers: frequencyDistribution(
field: "carrier"
) { value frequency }
attorney: frequencyDistribution(
field: "attorneyBarNumber"
) { value }
totalReserves: sum(field: "reserveAmount")
claimCount: count
}
}
}
}
Carriers Spell Names Differently.
Tilores Doesn't Care.
Jamal Booker at GEICO. Jamal Buker at Allstate. Different phone formats. Different address notations. One person — resolved via DOB + phone + ZIP fuzzy match. The typo never reaches the match engine.
ETM normalization runs before matching — raw formats never touch the rules engine
SIU analysts author normalization rules in the UI — no engineering ticket
Conflicting DOB or SSN-last-4 blocks the merge — no false positives
Every merge produces an auditable edge with the rule ID that fired
# One entity — despite the name typo
{
search(input: {
parameters: { mobile: "3055550877" }
}) {
entities {
id
records {
firstName # "Booker" vs "Buker"
carrier
mobile # raw format differs per carrier
normalized {
mobile # E.164 on all records
}
}
}
}
} How Tilores Works
A three-stage inline pipeline handles normalization, matching, and assembly — with separate rule sets that prevent the most common failure mode at scale: over-merging.
Raw Record Intake
Any record format — claims JSON, EDI 837, flat files — ingested via GraphQL mutation. Sync: returns the resolved entity in the same call.
Domain Normalization
Phone numbers → E.164, addresses → USPS canonical, name encoding variants — normalized inline via your ETM rules. Your SIU team changes normalization from the UI. No re-deploy.
Rule-Based Assembly
Normalized records match against the entity graph. Consistency rules block merges on conflicting DOB, SSN-last-4, or DL number. Every edge is auditable.
What makes two records the same person
High-confidence signals only. Putting weak signals here would collapse the entire ring to one entity — a known anti-pattern that Tilores' rule linter actively blocks before deployment.
What makes two persons suspicious together
Weak signals used as search anchors, never as merge criteria. Provider NPI, attorney bar, vehicle VIN — they surface rings without creating phantom super-entities.
Deployed in Your AWS Account
Tilores runs serverless in your VPC. No carrier data leaves your perimeter. No Tilores staff can access your records. The deployment is managed — the infrastructure is yours.
Real-Time FNOL
Sync ingest returns the resolved entity in the same call. Use dryRun: true to preview a merge without persisting.
Record Deletion
Delete individual records and entities re-assemble automatically. Required for GDPR, CCPA, and end-of-retention compliance.
Entity Stream
Every entity change triggers a downstream event — push merged identities to Snowflake, Salesforce, or your SIU queue without polling.
No In-Memory Wall
Sharded serverless index scales to any record count with no migration, no capacity planning, no downtime windows.
What a Technical Engagement Looks Like
No slides. No generic demos. Here is exactly what happens.
Schema Mapping · 30 minutes
We review your carrier record schema and configure ETM normalization rules together. No integration work required upfront — Tilores adapts to your field names and data formats.
Live Demo on Your Schema · 60 minutes
We build a synthetic dataset matching your carrier data shape, ingest it into a live instance, and run the fraud ring queries in real time. You see actual GraphQL responses — not a slide deck.
2-Week Shadow Mode · optional
Tilores ingests the same source records as your existing system in parallel. We compare resolved entities side-by-side. No cutover, no risk, no commitment required to proceed.
See What's in Your Carrier Data
We run a 60-minute technical demo against a synthetic dataset matching your schema — live queries, real entity resolution results. No slides.
Or reach us at sales@tilotech.io
Common Questions
How does Tilores handle very large record volumes? +
Sharded index, persisted assembly. Single-anchor weak-signal searches use composite indices (e.g. NPI + loss state) for selectivity, so query latency stays bounded regardless of total record count. There is no in-memory wall — the architecture is serverless on AWS Lambda and DynamoDB, and scales with zero migration or downtime.
What about consistency requirements and audit trail? +
Every merge produces an edge with the rule ID that fired — e.g. recA:recB:linkrule-phone-dob-zip. The why and how are queryable via the edges field on any entity. Consistency rules can hard-block merges on conflicting DOB, SSN-last-4, or driver's license number, and that decision is logged — not silently discarded.
Can Tilores integrate at FNOL, before a claim is filed? +
Yes. Ingest is synchronous — Tilores returns the resolved entity in the same API call. Use submitWithPreview { dryRun: true } to ask "would this record merge with anything?" without persisting. Your FNOL workflow gets an answer in under 500ms.
We have an existing entity resolution system in production. Do we need to migrate immediately? +
No. Tilores can run in parallel with your existing system — ingesting the same source records, resolving independently. Compare entity outputs side-by-side for 2–4 weeks and make a migration decision based on actual results, not a product pitch.
Can we be sure carrier data stays within our own infrastructure? +
Yes — that is a core design principle. Tilores is deployed inside your own AWS account. Your data never leaves your VPC, and no Tilores staff can access your records. We manage and update the infrastructure remotely, but it runs entirely within your perimeter.