Industries

Azure and AI for financial services and insurance

Financial services buyers are not slow because they are cautious. They are slow because every decision has to survive an examiner, an institutional client's due diligence questionnaire and an internal audit that will read the change log. Architecture either produces those answers or it does not.

Three constraints that make this sector different

You have to be able to explain your cloud, and to leave it. OSFI’s expectations on technology and cyber risk and on third-party risk management ask for things most cloud estates cannot produce on demand: a current register of material arrangements, a view of concentration risk, and an exit path that has been tested rather than written. An environment nobody can describe control by control is a finding waiting to be written up, and the remediation always costs more than doing it in the design.

Change control is the throughput ceiling, and it is usually the wrong control. The two-week approval cycle is not caused by the review. It is caused by assembling proof that the review happened: screenshots, tickets, a spreadsheet reconciled by hand. Teams respond rationally by batching a month of changes into one release, which is precisely the risk the control was meant to reduce. Until approval, artefact and deployment are the same record, the process makes the estate less safe, not more.

Every copy of the data has to be accounted for. The analytics sandbox, the vendor extract, the actuarial workbook on a laptop, the training set for the model somebody prototyped last quarter. Residency is contractual before it is legal: institutional clients and reinsurers write it into agreements and then verify it. The question is never whether personal data is protected in the production database. It is where the seventh copy went.

What we build here

  • A landing zone with a control narrative attached. Management groups, subscription vending, Azure Policy sets where each policy is mapped to the control it satisfies, and region restriction enforced so residency is a denied deployment rather than a promise. The Azure landing zone ships as Terraform you own, which is also the first page of the exit plan.
  • A private data plane. Private Link and private endpoints on every data service, no public endpoints on databases, hub-and-spoke with Azure Firewall, and Application Gateway with WAF as the only public entry. This is the part a due diligence questionnaire actually examines.
  • Identity built for the auditor’s first question. Microsoft Entra ID with conditional access, Privileged Identity Management so standing admin rights stop existing, scheduled access reviews, and workload identities with federated credentials instead of secrets in pipelines. See cybersecurity and Entra ID.
  • Evidence as a by-product of deploying. Defender for Cloud regulatory compliance dashboards, Microsoft Purview for classification and lineage, Azure Monitor and Microsoft Sentinel with ingestion sized honestly rather than sold by the gigabyte. Evidence is exportable per control, which is the difference between an audit that costs a week and one that costs a quarter. That discipline is compliance architecture.
  • Governed reporting and grounded AI. A lakehouse and Direct Lake semantic models with row-level and object-level security in Microsoft Fabric, then AI engineering on top: retrieval with security trimming, prompt and response logging, content filtering, inference inside your tenant.

An anonymized scenario

Anonymized scenario, not a named client.

A mid-sized insurer receives claims documentation as email attachments dropped into a shared folder. Three people triage them, key the values into the claims system and file the original. The backlog is measured in days and grows every storm season. The obvious project is Document Intelligence over the intake, and the extraction works in a fortnight.

The engagement is spent elsewhere. Where the documents land and under what retention. How the extracted values are confidence-scored so a human reviews the uncertain ones instead of rubber-stamping all of them. How an adjuster sees which page a figure came from. What is logged, for how long, and how that log is produced for an examiner without a person compiling it. And what happens on the day the model returns a wrong number, because that day is in the plan, not in the incident report. The measurable outcome is triage time per claim against a baseline recorded before anything was built.

Regulatory context we design against

In Canada, OSFI guidance on technology and cyber risk and on third-party risk management for federally regulated institutions, and the Autorité des marchés financiers for provincially regulated insurers and dealers in Quebec. Quebec Law 25 governs personal information handling, including the privacy impact assessment required before a transfer outside the province, which is covered in detail on our Law 25 compliance page. PIPEDA elsewhere in Canada. In the United States, SOC 2 Type II is the currency of vendor due diligence, with GLBA and state privacy law behind it. ISO 27001 and PCI DSS where card data is in scope. We do not write your policies. We build the estate so that each of those obligations maps to a control that is enforced by the platform, logged automatically and exportable on the day it is asked for.

Questions we get

Does Azure satisfy OSFI expectations on its own?

No. Microsoft supplies the platform, the attestations and the region. What an examiner asks about is your side of the line: how the environment is segmented, how privileged access is granted and reviewed, how change is approved and evidenced, and whether the exit plan has been tested. Those are architecture and process, and they are what we build.

We are mid-sized and do not have a cloud risk team. Is this proportionate?

The requirement scales with the assets and the data, not with headcount. A hundred-person insurer holds policyholder data with the same sensitivity as a national carrier. We scope the architecture to the organization and keep the controls intact, because the controls are what the examiner and the institutional client are both asking about.

How do we prove data residency rather than assert it?

Region restriction is enforced by Azure Policy at the management group level, so a subscription owner cannot deploy outside the allowed regions, and the attempt is denied and logged. That log is the evidence. A statement in a policy document that nobody can enforce is the version that fails a review.

Our change advisory board takes two weeks. Will this make it worse?

It usually makes it better, because the delay is rarely the review itself, it is assembling proof that the review happened. When approval, artefact and deployment are linked in the pipeline, the board reviews a diff rather than a narrative, and teams stop batching a month of changes into one high-risk release.

Can we use generative AI on policyholder or client data?

With deliberate boundaries. Inference stays inside your tenant, retrieval respects the permissions the user already has on the source record, every prompt and response is logged, and what the system may not do is written down and enforced. The hard part is not the model, it is proving that no copy of the data left the perimeter.

What does an exit plan actually look like?

Infrastructure as code you own, data in open formats with a documented extraction path, dependencies on proprietary services listed with a named alternative for each, and a rehearsal rather than a paragraph. Any provider unwilling to write down how you leave is telling you something.

Bring us the workload. We bring the architecture.

Thirty minutes, one architect, no deck. Come with a problem and leave with an opinion you can act on.