Every mobile phone ever manufactured carries a unique 15-digit number burned into its hardware at the point of production. It cannot be legitimately changed. It cannot be transferred to another device. It is recorded in international databases the moment the device is registered on a network. That number is the IMEI — the International Mobile Equipment Identity — and it is the single most reliable identifier available for verifying a device's true identity.
Every fraudulent mobile phone insurance claim has a problem with that number.
Maybe the IMEI belongs to a device reported stolen by someone else. Maybe the number has been entered correctly but belongs to a completely different phone model than the one being claimed. Maybe the device has been blacklisted by a network operator after being flagged for suspicious activity. In each case, the IMEI tells the truth when the claimant does not.
For years, insurance repair centres received mobile phone claims without ever checking it. Not because they didn't know about IMEI verification — but because there was no system at the point of intake to do it automatically. Claims were booked, jobs were created, and the verification (if it happened at all) came later, after technician time had already been spent.
We built the IMEI Verification API Integration during the Connect NZ era (2019–2020) to close that gap. Real-time device verification embedded directly into the FileMaker Pro claims booking workflow — so that by the time a job record was created, the device had already been checked. This is the story of how a two-second API call became a fraud prevention layer.
How much does device insurance fraud actually cost?
Insurance fraud in New Zealand is not a fringe problem. The Insurance Council of New Zealand estimates that fraud costs the industry hundreds of millions of dollars annually across all claim types. Mobile device and electronics claims are a disproportionately high-fraud category: the devices are valuable, portable, easily misrepresented, and the claim assessment process historically relied heavily on the claimant's self-reported account of what was damaged and when.
The most common fraud patterns in device claims follow predictable templates. A claimant submits a claim on a device that was actually stolen — they report it as accidentally damaged because accidental damage is covered and theft (in their situation) might not be, or they are claiming on a device they know belongs to someone else. A claimant misrepresents the device model, claiming a higher-value handset than they actually own to receive a more valuable replacement. A device is submitted for a second claim after already being settled once, either by the same claimant or after being sold.
Device insurance fraud is a high-value, high-frequency category — one that exploits the gap between claim intake and physical device inspection.
What makes device fraud particularly costly is when it is detected late. If a fraudulent claim is not caught at intake, it proceeds through the entire repair pipeline: assessment, parts ordering, technician time, customer contact. By the time the fraud is identified — often only when the physical device arrives and the damage or identity does not match the claim — significant operational resources have already been consumed. The fraud detection cost is compounded by the wasted work.
The economics are stark. Catching a fraudulent claim at intake costs nothing beyond the API call — a few cents. Catching it after job creation costs the labour, parts, and logistics already committed. Catching it never means paying out a fraudulent claim entirely. For a repair centre processing thousands of claims annually for major insurers like IAG, Vero, and Tower, the aggregate impact of late or no fraud detection is substantial.
The question was not whether fraud prevention was worth investing in. The question was where in the workflow to put the check.
What is an IMEI and why does it matter for insurance claims?
IMEI stands for International Mobile Equipment Identity. It is a 15-digit number assigned to every mobile device at the point of manufacture, stored in the device's firmware, and registered with international databases the first time the device connects to a mobile network. Unlike a serial number (which is manufacturer-specific and not universally tracked), the IMEI is globally standardised and globally traceable.
The authoritative source for IMEI data is the GSMA — the Global System for Mobile Communications Association — which maintains the IMEI database used by network operators, law enforcement, and verification services worldwide. When a device is reported stolen, the owning network operator can flag its IMEI in this database, blacklisting it from connecting to any cooperating network globally. This is the foundation of the stolen phone reporting system used across New Zealand and internationally.
Every mobile device has a unique IMEI burned into its hardware at manufacture. It is the most reliable single identifier available for insurance claims verification.
For insurance claims purposes, the IMEI matters for three reasons. First, it is the only reliable identifier that links a physical device to its registered model and history — it cannot be changed by the user, and any attempt to alter it is illegal in most jurisdictions. Second, it is queryable in real time against databases that track stolen devices, blacklisted IMEIs, and registered device specifications. Third, the registered model information tied to an IMEI allows cross-referencing against what the claimant has reported — a mismatch between the claimed model and the IMEI-registered model is an immediate flag.
The IMEI is, in essence, a device's permanent identity document. For a claims system that relies on the claimant to accurately self-report what they own and what happened to it, having an independent, automated way to verify the device's true identity is the difference between trusting and verifying.
An IMEI verification API call returns several pieces of information: device status (clean, stolen, blacklisted, or barred), the manufacturer and model registered to the IMEI, network lock status, and in some cases, purchase date and original carrier. Each piece of information adds a layer of verification against the claim being submitted.
Where in the claims workflow does fraud actually get through?
Understanding why fraud was getting through requires mapping the exact claims intake workflow that existed before verification. A claimant contacts the repair centre — either by phone, via insurer referral, or through a web portal. The booking agent opens a new claim record in FileMaker Pro. They enter the claimant's details: name, contact information, policy number, insurer. They then enter the device details: manufacturer, model, storage capacity, colour, and IMEI.
That last field — the IMEI — was a text box. The agent typed what the claimant told them, or transcribed it from an email or insurer referral document. Then they moved on. No check was made. No database was queried. The IMEI was recorded and that was the end of it.
In a manual claims workflow, the IMEI is recorded but never checked. Fraud enters at exactly this point — between intake and physical inspection.
The gap between intake and physical device inspection was where fraud lived. Once a job record was created, the repair centre's operations began: parts were allocated, a technician was scheduled, the customer was contacted with a booking time. All of this activity happened against a job that might — if the IMEI was fraudulent — have no legitimate basis at all.
The fraud was eventually caught, but not at intake. It was caught when the physical device arrived and the technician noticed the model did not match. Or when a more experienced agent recognised a pattern. Or — in the worst cases — not until the insurer queried the claim during a periodic review. By then, the operational cost of the fraudulent claim had already been incurred.
Manual verification was not a realistic alternative. A booking agent handling 20 to 40 claims per day cannot manually cross-reference each IMEI against stolen device databases in real time. The GSMA database is not publicly accessible — it requires API credentials and an integration to query programmatically. And even if the data were accessible, the time pressure of a busy claims queue made a manual lookup workflow impractical. The verification needed to be automatic, invisible, and immediate.
The services brief was clear: add verification at the exact point of intake, with zero impact on the workflow for legitimate claims and immediate flagging for fraudulent ones.
How does real-time IMEI verification work at the point of claim intake?
The integration embeds a live API call into the FileMaker Pro claim booking workflow at the exact moment the IMEI field is completed. When the booking agent enters the IMEI and moves to the next field — a tab or a click — FileMaker executes a script that constructs an authenticated HTTPS request to the IMEI verification API, waits for the response (typically under two seconds), and writes the result to the claim record in real time.
The agent sees a colour-coded status indicator update on the same screen they are already working on. A green indicator means the device is verified — clean IMEI, model matches the claim, no flags. The agent proceeds to job creation without any additional steps. For legitimate claims, the verification is effectively invisible: two seconds and a green tick.
The verification call is invisible to legitimate claimants — it adds two seconds and a green tick to the agent's screen. For fraudulent claims, it surfaces a flag before a single job record is created.
For flagged claims, the indicator changes colour and displays the specific reason: red for blacklisted or stolen, orange for model mismatch, yellow for format error. The FileMaker workflow prevents job creation from proceeding without a supervisor override when a red flag is triggered. The claim record is automatically marked as requiring review, an alert is sent to the operations manager, and the specific verification failure is logged against the record with full API response details.
The integration required three components. First, API credentials for an IMEI verification service with access to GSMA-backed stolen device data — a commercial API that returns device status, registered model, and network information. Second, a FileMaker script that constructs the API request, handles authentication, parses the JSON response, and writes the relevant fields to the claim record. Third, UI changes to the existing booking form: the status indicator field, the conditional colour logic, and the supervisor override workflow for flagged claims.
The approach kept the existing workflow intact for the majority of claims. Agents did not need retraining — the form looked the same, the process was the same, and the only visible addition was a status field that was almost always green. The complexity was in the exception handling: what the system did when the API returned a flag, how it surfaced that information to the right people, and how it prevented fraudulent job records from being created while maintaining a clean audit trail.
What does IMEI verification actually catch?
The verification system detects four categories of issue, each mapped to a specific response:
Stolen or blacklisted devices are the clearest fraud signal. When an IMEI is returned as stolen or blacklisted by the API, the claim is almost certainly fraudulent — either the claimant is attempting to claim on someone else's reported stolen device, or they have reported the device stolen themselves and are now attempting to also claim accidental damage. Job creation is blocked automatically. The insurer is notified. The case is escalated.
Model mismatches occur when the IMEI-registered device does not match the manufacturer or model the claimant has reported. A claimant who says they are submitting a claim on an iPhone 15 Pro Max, but whose IMEI is registered to a mid-range Android handset, is misrepresenting the device value to receive a higher-value replacement. This triggers an orange warning rather than an automatic block — the agent and supervisor review the discrepancy before proceeding.
Each verification outcome maps to a specific response — from immediate job creation to automatic flagging and supervisor escalation.
Format errors are caught before the API call is even made. A valid IMEI is exactly 15 digits and passes the Luhn algorithm — a checksum formula used to validate the number's internal consistency. If the entered IMEI fails either check, the system flags it as a format error immediately, without consuming an API call. This catches transcription errors (agents misreading or mis-entering an IMEI from a document) before they become records in the system.
Previously claimed devices are tracked against the repair centre's own claim history. If an IMEI appears in a completed claim record, a duplicate alert is triggered. This catches cases where the same device is submitted for multiple claims — either by the same claimant or after being sold to a new owner who then attempts to claim on pre-existing damage.
The system does not catch all fraud. A claimant with a legitimate, clean IMEI submitting a fabricated damage story will pass the IMEI check. Sophisticated fraud involving IMEI alteration (illegal and technically complex) is a different problem requiring different detection methods. What IMEI verification does exceptionally well is catch device identity fraud — the category of fraud that relies on misrepresenting what device is being claimed. In a device claims environment, this is the most common and most financially significant fraud vector.
What changed when the verification layer went live?
The immediate effect was visible within the first weeks of deployment. Claims that previously would have proceeded to job creation were surfacing flags — blacklisted IMEIs, model mismatches, format errors that revealed agents had been recording incorrect IMEI numbers for months. These were not hypothetical risks; they were real claims being flagged in real time.
The data quality improvement was an unexpected dividend. Format error flags revealed that a non-trivial percentage of IMEIs in existing records were incorrectly entered — wrong number of digits, transposed characters, numbers copied from the wrong field on a document. The verification system did not just prevent fraud; it revealed a data quality problem that had existed silently in the claims records for years. Going forward, every IMEI in the system was validated before it was stored.
The shift from manual to verified intake changed more than fraud detection — it improved data quality, staff confidence, and the repair centre's standing with insurer partners.
Staff confidence in the claims intake process shifted noticeably. Booking agents who had previously had no way to verify what they were being told now had an objective check running behind their workflow. The green tick on a legitimate claim provided reassurance. The flags on suspicious claims gave agents a clear, system-backed reason to escalate rather than having to rely on their own suspicion — which, in a high-volume claims environment, is a significant operational benefit.
Insurer partners noticed. The ability to demonstrate that real-time IMEI verification was embedded in the intake workflow became part of the commercial conversation with IAG, Vero, and Tower. It was evidence that the repair centre was investing in fraud prevention as a shared concern — not just processing claims at volume, but actively working to protect the insurer's exposure. This kind of trust-building is difficult to quantify in a spreadsheet but materially affects the depth and stability of insurer relationships.
This verification layer was one piece of the insurance claims technology stack we built during the Connect NZ era — work that now informs how we approach ClaimPilot and the insurance and property practice at EmbedAI.
What does this mean for insurers choosing repair partners in New Zealand?
New Zealand's device insurance market is concentrated. IAG, Vero, and Tower handle the majority of personal device insurance policies. Their repair and replacement programmes route through a small number of authorised repair providers. The commercial relationships that govern these programmes are not purely transactional — they are built on demonstrated capability, compliance, and trust.
Insurers evaluating repair partners ask questions that go beyond price and turnaround time. What fraud controls are in place? How is data handled? What happens when a fraudulent claim is submitted — is it caught, and how quickly? What is the audit trail? These questions reflect the fact that the insurer's exposure does not end when they refer a claim to a repair provider — it extends through every step of the process.
IMEI verification capability became a commercial differentiator — a signal to insurer partners that data integrity was a priority, not an afterthought.
Adding real-time IMEI verification to the claims intake workflow was not only a fraud prevention measure — it was a commercial signal. It demonstrated that the repair centre was investing in the same problem the insurer cared about. Every flagged claim was not just a prevented loss; it was evidence that the system was working, and that evidence could be reported back to the insurer.
The pattern holds beyond device insurance. Any business that handles third-party data on behalf of a partner — financial services, healthcare, logistics, legal — faces the same dynamic: trust is built through demonstrated investment in data integrity, fraud controls, and audit capability. A real-time verification check at the point of intake is one of the clearest ways to demonstrate that investment, because it addresses the risk before it becomes a cost.
The technical implementation was straightforward. The commercial implications were significant. That asymmetry — low technical complexity, high business value — is a recurring feature of well-placed automation and integration work. The right API call, at the right point in the workflow, can change the nature of a commercial relationship. In this case, it changed a repair centre from a provider who processed claims to a partner who protected against fraud.
This kind of foundational integration work — building reliable, auditable data systems into existing workflows — is the foundation that later AI-powered solutions like Smart Assess and ClaimPilot are built on. The progression from IMEI verification to computer vision to AI claims matching follows a single thread: start with data integrity, then add intelligence.
What technology powers the IMEI verification integration?
IMEI Database API — Real-time lookup against international IMEI databases backed by GSMA registries. Returns device status (clean, stolen, blacklisted, barred), registered manufacturer and model, and network lock status. Authenticated HTTPS requests with JSON responses. Typical response time under two seconds.
FileMaker Pro — Existing claims management system serving as the integration point. FileMaker scripts handle API request construction, authentication header management, response parsing, and result writing to the claim record. UI changes add the status indicator field and conditional colour logic to the existing booking form.
API Response Handling — Four outcome states with distinct workflows: verified (green, job creation proceeds), blacklisted/stolen (red, job creation blocked, supervisor alert triggered), model mismatch (orange, warning surfaced for manual review), invalid format (yellow, entry error flagged before API call via Luhn algorithm check).
Audit Trail — Every verification check logged against the claim record: timestamp, IMEI queried, API response code and parsed result, agent username. Provides full audit trail for insurer reporting, internal review, and dispute resolution.
Duplicate Detection — Cross-reference of incoming IMEI against existing claim records in the FileMaker database. Flags claims where the same device IMEI has appeared in a previous completed or active job, triggering a duplicate alert for manual review.
FAQ
What is IMEI verification and how does it prevent insurance fraud?
IMEI (International Mobile Equipment Identity) verification checks a device's 15-digit identifier against international databases of stolen, blacklisted, and reported devices. In insurance claims, it catches fraudulent submissions where a claimant attempts to claim on a stolen device, a device reported lost by someone else, or misrepresents the device model. The check happens in real time during claim intake — before any job record is created — and returns a result in under two seconds.
Can IMEI verification be integrated into any claims management system?
Yes. Any system that captures device details during claims intake can be extended with real-time IMEI verification via API. FileMaker Pro, Salesforce, ServiceNow, and custom web applications all support API integration. The core pattern — capture IMEI, make an authenticated API call, handle the response — is the same regardless of the underlying system. Complexity varies by platform, but the integration is typically a straightforward development task once the API credentials are established.
What happens to a claim when the IMEI check fails?
The system surfaces the specific failure reason to the booking agent immediately: blacklisted, stolen, model mismatch, or format error. Job creation is blocked automatically for clear fraud signals (blacklisted/stolen) or flagged for supervisor review for ambiguous cases (model mismatch). The insurer is notified for blacklisted and stolen outcomes. Every failed check is logged against the claim record with the full API response for audit purposes.
Does IMEI verification catch all fraudulent insurance claims?
No single check catches all fraud. IMEI verification is highly effective at catching device identity fraud — stolen devices, blacklisted IMEIs, and model misrepresentation. It does not detect fraud involving legitimate devices with fabricated damage, or highly sophisticated IMEI manipulation. It functions as one layer in a fraud prevention stack, and a cost-effective one: each API call costs a few cents and adds under two seconds to the intake process.
Can EmbedAI add device verification or data validation to our claims workflow?
Yes. The IMEI verification integration is one example of embedding real-time third-party data validation into existing workflows to improve data quality and catch fraud at the point of intake. Whether you're working with insurance claims, asset management, or any workflow where device or identity verification matters, contact EmbedAI to discuss integration options.