Case Study · Secure Regulatory Data API
The client turns insurance rate filings into analytics its customers price and plan against. Letting partners and machines reach that data meant building an entry point that could survive being public. We scoped a serverless filing API on Google Cloud: three layers of defence before any logic runs, machine-to-machine authentication with short-lived tokens, query functions isolated in a private VPC, secrets the administrators cannot read, and every resource provisioned as code.
Representative request path drawn from the scope document's end-to-end workflow. The database is never adjacent to the public endpoint, and the private key never leaves Secret Manager.
Steps from key issue to API response
Platform components in the Phase 1 scope
Layers of defence before any logic runs
Design principles the architecture answers to
The client
An InsurTech rate-filing analytics company whose platform turns insurance rate filing data into visual analytics and generated reports for pricing and strategy teams. Identity withheld at the client's request.
The challenge
That data had to become a public API for partners and machine consumers - without giving the internet a route to the database, or to the credentials behind it.
The build
A serverless filing API on Google Cloud: API Gateway behind a load balancer and Cloud Armor, Python Cloud Functions in an isolated VPC, secrets held outside admin reach, all defined in Terraform.
What it delivers
List, search and view filings over an authenticated API - plus an admin dashboard for issuing access and watching usage per account.
01The client
The client is an InsurTech company built on regulatory rate filings - dense, slow-moving public documents that insurers, reinsurers and analysts need to read comparatively rather than one at a time. The platform turns that material into visual insight and generated reports, so a pricing or strategy team can see how a market is actually moving instead of working through filings in sequence.
That product already existed and already worked. What did not exist was any way for anyone else to reach the underlying data programmatically. A customer who wanted filings inside their own pricing model, a partner building a service on top of the dataset, a machine consumer pulling on a nightly schedule - every one of them needed an interface, and an interface means a public endpoint.
Focaloid was engaged to scope that endpoint: a secure backend that streamlines the retrieval, filtering and monitoring of regulatory insurance data, and can be handed to a third party without handing over anything else.
The shape of the problem
The client's data has commercial value precisely because it is curated and complete. That is also exactly what makes uncontrolled access expensive - this was a security requirement arriving in the shape of a product decision.
The structural tension that shapes every decision downstream.
An open door
A closed system
Between them sits the requirement the whole architecture answers - the entry point has to be public, and everything behind it has to be unreachable.