Claims Intake Integration Layer

Claims arrived at the back office through four channels — a broker portal, email attachments, a partner API and a call centre tool — and each landed in a different place with different fields. Staff rekeyed most of them into the core system by hand, which was slow and where nearly all data errors came from. Nobody could say how many claims were in progress at a given moment because there was no single point where a claim entered the business. The team wanted one intake path that all four channels fed, with routing rules that could change without a release.

I was one of two senior engineers on a team of about nine, in an employed role rather than a contract. I owned the integration layer and the routing engine; the other senior engineer owned the core system changes on the other side of it. I also did a fair amount of unglamorous work chasing broker technical contacts for specifications that turned out not to match what they actually sent.

I wrote the intake API and the four channel adapters that normalise into it, including the email adapter that parses attachments and quarantines what it can't read rather than guessing. I owned the routing engine — the rules are data, editable by the operations team through a small admin screen, with a dry-run mode so they can see where a rule change would send things before saving it. I built the retry and dead-letter handling around the queue, and the reprocessing tool for claims that failed on a bad rule. I didn't own the core system integration itself, only everything up to the point where I handed the claim over.

I made routing rules data rather than code specifically because the operations team changed their minds roughly monthly, and every change was previously a two-week release cycle. The cost is that a bad rule can now misroute claims quickly, which is why I built the dry-run mode before shipping the editor rather than after. I also chose to quarantine unparseable email claims for human review instead of best-effort extraction; the team initially wanted extraction with a confidence score, and I argued that a wrong claim silently entering the pipeline is far worse than one sitting in a tray. Message ordering was deliberately not guaranteed — I made every downstream step idempotent instead, which was cheaper than the alternative.

The core system is a vendor product with a fixed API and a support contract that made changes slow, so the integration layer had to absorb every mismatch. Two of the broker channels couldn't be modified at all because the brokers are external and had no appetite for work. There were also strict rules about where claim data could live, which ruled out a couple of managed services I'd otherwise have used and meant running our own queue infrastructure.

Manual rekeying dropped from most claims to the quarantine tray only, which runs around six to eight percent of intake, nearly all of it email. Average time from a claim arriving to it being visible in the core system went from hours — sometimes a day for email — to under two minutes for the automated channels. The operations team has changed routing rules more than thirty times since launch without an engineer involved. The number I care about most is that we can now answer how many claims are in progress, which was genuinely unanswerable before.

The other senior engineer and I traded reviews on everything and disagreed usefully about where the boundary between our systems sat. A business analyst on the operations side wrote the routing rules with me and was the one who insisted on dry-run mode. Two junior engineers built the admin screen and the quarantine tray, and did a better job on the tray's usability than I would have.