An insurance carrier is one of the very few businesses whose product is a database record. There is no factory, no stock, no fleet - the policy is the system entry, the claim is the workflow, and the reserve is a calculation. Which means that in insurance, unusually, a technology decision is not a decision about how the business is supported. It is a decision about what the business is capable of selling and how accurately it can say what it owes.
That is why the failure modes here look different from everywhere else. A carrier does not usually discover it has a technology problem when something breaks. It discovers it when the actuary cannot get a clean loss triangle out of the claims system; when a new product takes months to launch because the policy administration system encodes products as code rather than configuration; when the regulator asks a question about claims handling and the answer has to be assembled by hand; or when the combined ratio moves in the wrong direction and nobody can decompose why, because pricing, underwriting and claims data live in three systems that classify risk differently.
The second structural fact about this market is that its regulation changed recently, and comprehensively. The Insurance Authority was established by Royal Decree No. M/85 dated 15 August 2023 and began work on 23 November 2023, taking over supervision of the insurance sector from the Saudi Central Bank (SAMA), and it has since become the sector's sole regulator - health insurance supervision moved to it from the Council of Health Insurance in March 2024. For a carrier, a regulator that is new, dedicated and building out its own supervisory framework means one thing above all: reporting obligations will move, and the systems that produce your returns need to be able to move with them. A data architecture that can only answer the questions it was originally built for is a liability under a supervisor still defining its questions.
Our interest, stated before the argument rather than after it. Trustangle is an independent advisory firm based in the Kingdom. We sell selection, architecture and implementation-assurance work, so we have a genuine commercial interest in your decision, and you should know that before you read further rather than discover it on a partners page afterwards. What we do not do is earn a margin on your licences or bid for the implementation we scoped. In a market with a small number of core-insurance platform vendors and a smaller number of integrators who have actually delivered one here, that separation is most of what we are offering.
Three pressures, and they compound: the regulatory one sets obligations that are reported on and examined, the operational one determines whether you can launch and service a product at all, and the data one is why the first two are more expensive than they need to be.
A carrier in the Kingdom answers to several authorities. The Insurance Authority regulates and supervises the insurance sector - licensing, conduct, solvency and prudential requirements, product approval and policyholder protection sit with it, and health insurance supervision moved to it from the Council of Health Insurance. SDAIA, through the National Data Management Office, governs data management and classification alongside the Personal Data Protection Law, which bears heavily on a business whose entire book is personal data - medical, financial and vehicular. The National Cybersecurity Authority sets the national control baseline. ZATCA governs tax and e-invoicing obligations on the transactions. And where a carrier distributes through banks or sells investment-linked products, the relevant financial-sector regulation applies to that channel as well.
The Saudi Central Bank (SAMA) remains the banking and payments regulator, and was the insurance supervisor until the transfer described above. It is named here only so the distinction is clear; nothing on this page treats SAMA as the current insurance regulator.
We are not going to quote you an article, a solvency ratio, a reporting template or a deadline on this page. Those change - faster than usual right now, precisely because the supervisory framework is being built out - a sector page carrying them is wrong within a year of being written and never says so, and your own compliance and actuarial functions are the authority on the current text. What is stable enough to be worth saying is the shape of the problem.
Your regulator's questions are about your data, and you cannot answer them faster than your worst system. Prudential and conduct reporting are not documents; they are queries over the policy, claims and finance record. When those three disagree - when the claims system's cause-of-loss taxonomy does not map to the actuarial one, when a policy endorsement history is reconstructed rather than stored, when the same customer is three records - every return becomes a reconciliation project, and the carrier absorbs that cost every single reporting cycle, forever.
Product approval is a systems constraint, not just a paperwork one. A product you cannot configure is a product you cannot vary, and a product you cannot vary is one whose approved terms and whose implemented terms drift apart. That drift is exactly what a conduct examination finds.
The work that breaks the cycle is deciding once which system owns each answer, and how it evidences itself continuously rather than on request. The control environment sits under IT security consulting.
The policy administration system decides your time to market. In most carriers we see, launching or varying a product means a development cycle, because the product is expressed in code rather than in a configurable product model. The commercial consequence is that the carrier competes on price rather than on product, because price is the only variable it can move quickly. The technical consequence is a regression-test burden on every launch. Whether product configuration is genuinely configuration is the single most consequential question to ask of any core platform, and the one most reliably answered "yes" in a demo and "no" in delivery - ask to configure a product yourself, live, in the sales cycle.
Claims is where the money and the reputation both are, and it is usually the least-invested system. Intake across channels, triage, assignment, survey and adjustment, supplier and repair networks, fraud referral, reserving, recovery and subrogation, settlement. Carriers routinely modernise the front end and leave the claims core alone, which produces a fast, attractive way to buy a policy attached to a slow, manual way to be paid for it. That is the wrong way round: a policy sale is a once-a-year interaction; a claim is the only moment the product is actually consumed.
Underwriting decisions made without the data that exists. Most carriers hold far more risk-relevant data than their underwriting rules use, because the data is in systems the rule engine cannot reach in the time a quote allows. The gap between "data we hold" and "data we price on" is one of the most measurable opportunities in a carrier's estate, and it is an integration problem before it is an analytics one.
Distribution is many channels with one back office that was built for one. Direct digital, aggregators, brokers, bancassurance, agents, corporate schemes. Each has different commission, quotation, binding and servicing behaviour, and each tends to get its own bolt-on. The result is a quote that behaves differently depending on where it came from, which is a conduct exposure as well as an operational one.
Capability leaves when the contract ends. Core-insurance platform skills are scarce and expensive, and carriers commonly contract them in. That works during delivery and fails afterwards: the people who know why the product model was built that way are gone at go-live, and the carrier cannot change its own platform without raising a variation. Knowledge transfer as a contractual deliverable with an acceptance test - not a goodwill clause - is the highest-return contractual change we recommend here.
Insurance is an actuarial business running on operational systems, and the join between those two facts is where most carriers' data problems live.
The recurring conditions: the customer is not a single record, so cross-sell, aggregate exposure and conduct obligations all rest on a join that is approximate. Policy history is stored as current state rather than as a full endorsement and version history, so "what cover was in force on the date of loss" is a reconstruction. Claims taxonomies differ between the operational system and the actuarial model, so loss development is rebuilt each quarter by hand. Reinsurance arrangements - treaty and facultative, cessions, recoveries, bordereaux - are managed in spreadsheets in a surprising number of carriers, which is a material financial-reporting exposure sitting outside every system control the carrier has. And motor, medical and property books frequently sit in separate systems acquired at separate times, so the group view is an extract.
This is why the ambitions that matter most are harder than they look. Real-time pricing, automated straight-through underwriting, fraud detection that works across claims rather than within one, and an accurate solvency and exposure picture each require several systems to agree about a customer, a policy version and a loss. Every one of those is a data-ownership decision before it is an interface. The boundary work is systems integration; the analytics layer that becomes possible once the boundaries hold is business intelligence & analytics, built on the platforms covered under data, AI & analytics and data analytics services.
What follows is what comes up in the conversations we are in with chief executives, CIOs, chief actuaries, heads of claims and heads of underwriting. It describes where attention is going. It is not a market forecast, and we have attached no percentage, premium volume or growth rate to any of it, for the reason section 8 sets out.
Core platform replacement, and the dread of it. A great many carriers know their policy administration system is the constraint and have deferred replacing it, because core replacement is the single riskiest programme an insurer runs. The live question is almost never "should we" - it is how to sequence it so the carrier is not betting the company on one cutover.
Claims as the investment priority. Claims automation is where the measurable savings and the measurable customer-experience gains both sit, and it is increasingly being funded ahead of the policy core because it can be done incrementally.
Underwriting automation and straight-through processing. Rules-based auto-acceptance for standard risks, referral only by exception, and machine assistance in pricing and risk selection. The constraint is data quality and the ability to explain a declined or loaded quote to a customer and to a supervisor - not the model.
Fraud detection across the book rather than within a claim. Network- and pattern-based detection needs claims, policy and party data joined, which is why fraud programmes so often stall on a data problem they did not budget for.
Digital distribution and the aggregator relationship. Being quotable, bindable and serviceable through every channel with one consistent answer, and knowing the true acquisition cost and loss ratio by channel.
Regulatory reporting that is produced rather than assembled. Under a new and active supervisor, the carriers investing in a reporting data layer now are the ones who will absorb the next template change as a configuration rather than a project.
Governance before AI. Interest in applying machine learning to pricing, triage, fraud and claims leakage is genuine and rising. The constraint is lineage, quality, ownership and the ability to explain an automated decision that affects a policyholder's claim or premium - to that policyholder and to a supervisor. Carriers that build governance first move faster afterwards, not slower.
Sector context. The financial-services technology agenda in the Kingdom shares a great deal of ground with insurance - customer data, regulatory reporting, fraud, digital distribution - and is set out on the banking & financial services page. The national reform context behind much of this demand is Saudi Vision 2030; the operating-model change it implies is covered under digital transformation.
We start from the decision you have to make and the date it has to be made by - not from a discovery phase with an open end.
First, establish what is actually true. The estate as documented and the estate as operating differ in every carrier we have worked in. We read the product inventory against what is actually sold, the policy and claims data model against the questions the actuarial and regulatory functions actually ask of it, the integration inventory, the incident record, the manual workarounds in claims and underwriting (which are the most honest description of a system's real gaps), the committed run cost with its contract renewal dates, and where the knowledge sits - which capabilities you could still operate if a particular supplier left next month.
Second, separate the decisions from the noise. Most carrier estates present as dozens of competing problems and resolve into a handful of genuine decisions: whether the product model is configuration or code, which system is the system of record for the customer and for the policy version, whether claims is replaced or wrapped, whether reinsurance comes inside a system, and what you must be able to change yourself after handover.
Third, put options in front of you with their costs and their risks. Each option carries what it costs to run over several years rather than to buy, what it forecloses, what has to be true for it to work, and how it fails. Where the decision goes to procurement, requirements have to be specification-neutral and genuinely evaluable so that more than one capable supplier can answer them - a requirement lifted from one vendor's datasheet is a single-source award with extra steps. That discipline is set out under technology vendor selection.
Fourth, sequence against the constraints that do not move. Reporting cycles, the financial year, product approval timelines, renewal seasons - a motor book's renewal peak is not a migration window - and the reality that data migration in insurance is harder than in almost any other sector, because you are migrating not just current state but the history a claim may be decided on years from now.
Fifth, stay accountable through delivery, and leave capability behind. Where we are engaged past the decision we work as design authority and assurance - holding the architecture boundaries the decision depended on, reviewing what the implementer is actually building against them, and saying so when the two diverge. We treat transfer of knowledge to your own team as a deliverable with an acceptance test.
We work in capability categories rather than product names, because the right answer depends on the book you write and the estate you already have.
Policy administration and product configuration. Quotation, underwriting, binding, endorsement, renewal and cancellation, with a product model that is genuinely configurable across the lines you actually write - motor, medical, property, marine, engineering, liability, life and savings all make different demands of it.
Claims management. Intake across channels, triage and assignment, survey and adjustment, supplier and repair-network management, reserving, fraud referral, recovery and subrogation, settlement and payment. This is where the measurable operational gain is.
Underwriting workbench and pricing. Rules-based straight-through processing for standard risks, referral by exception with a full audit of who decided what and why, and a pricing capability that can consume the data the carrier already holds.
Distribution and digital channels. Broker and agent portals, aggregator integration, bancassurance, corporate scheme administration, direct digital sale and self-service - all answering consistently from one product and one price.
Reinsurance, finance and actuarial data. Treaty and facultative administration, cessions and recoveries, bordereaux, and the reporting layer the actuarial and finance functions work from. Moving reinsurance out of spreadsheets is one of the most under-rated risk reductions available to a mid-sized carrier.
Data platform, governance and regulatory reporting. The warehouse or lakehouse, the governance, classification and lineage that make outputs defensible to a supervisor, and reporting produced by a pipeline rather than assembled by a team.
Cybersecurity, fraud and identity. Control implementation across the estate rather than per system, identity and access management, fraud detection, and continuous control evidence.
The requirement document is the decision. By the time bids are evaluated, most of the outcome has been determined by how the requirements were written. In core insurance the number of suppliers who can credibly carry a full policy-and-claims workload is small, so a requirement that narrows the field even slightly narrows it to one. An adviser who will not bid can write requirements that several capable suppliers can genuinely answer.
We do not earn a margin on your licences. An adviser whose revenue rises with the size of the implementation cannot credibly tell you the implementation should be smaller. We can, and it is frequently the advice - that the platform you already own covers the requirement, that claims should be fixed before the policy core, that the module being proposed solves a problem you have not got.
Someone who can disagree with the incumbent. An independent design authority does not displace a long-standing integrator's institutional knowledge. It restores the second opinion that a single-supplier arrangement removed.
A decision that survives the record. In a regulated carrier, the file supporting a major platform decision is read again - by internal audit, by the board's risk committee, and by whoever inherits the contract. Running the evaluation independently of anyone who benefits from its outcome is what makes it defensible.
And the limits, stated honestly. Independence is not omniscience - we will not understand your book, your underwriting appetite or your regulator better than your own actuarial, underwriting and compliance functions do. It is also not the same as having no interest: we sell advisory work, and where we hold a partnership or accreditation with a vendor it is published on our partners page rather than implied in copy. Ask us directly whether we hold one with any supplier you are evaluating, and ask every other adviser bidding the same question.
There is no case study on this page, and the reason is not modesty. Naming a carrier and describing its estate needs that carrier's specific permission for that specific purpose. The detail that would make the story useful - what was failing, what the loss ratio did, what the migration actually cost - is precisely the detail that does not get cleared, and in a regulated and often listed business some of it is market-sensitive regardless of willingness. Where a client has agreed, the account is on our success stories page with the detail they approved.
The alternative is the anonymised composite - "a leading regional insurer" - and it is worse than an empty section. That construction permits any claim at all, because no organisation exists that could contradict it, and a reader cannot distinguish a real anonymised engagement from an invented one.
What we will do instead costs you an hour. In a first conversation we will talk in specific detail about work of a shape close to yours - what the estate looked like, where the real constraint turned out to be, what we recommended, what went wrong that we did not foresee, and what we would do differently - within the confidentiality each client is owed.
Five recur. A policy administration system whose products are code rather than configuration, so time to market is a development cycle. A claims core that was left alone while the front end was modernised. Underwriting decisions made without data the carrier already holds, because the integration is not there. Policy history stored as current state rather than as versions, so "what was in force at the date of loss" is a reconstruction. And reinsurance administered outside any system control. They compound: the history problem inflates the reporting cost, and the integration problem is why fraud and pricing programmes stall.
Most carriers need a policy administration system with a genuinely configurable product model across the lines they write; a claims system that handles intake through settlement with real supplier and reserving support; an underwriting and pricing capability that can reach the data the carrier holds; distribution channels that answer consistently; reinsurance administration inside a system rather than a spreadsheet; a data platform with governance good enough to defend a supervisory return; and the security and identity controls an estate made entirely of personal data requires. What varies is how much of that is separate software rather than capability inside something you already own. Be alert to buying the same capability twice - party management in three systems, rules engines in four - which happens whenever nobody decides which system owns the decision.
We are not going to publish a figure. Duration here is set by the number of product lines in scope, the state and depth of the history being migrated, the cutover strategy, the reporting and renewal calendars, and the availability of a small number of people who understand the existing product model. What we can offer is how to read an estimate. Ask whether it begins at the decision or at contract signature. Ask what proportion is data migration - and specifically whether history, not just current state, is in scope, because a claim decided years from now will be decided on it. Ask whether the plan is a single cutover or line-by-line, and what the rollback is. Ask whether decommissioning of the replaced system is inside the price. And ask which named individuals are committed to your dates rather than pencilled against them.
At the level of institutions rather than clauses: the Insurance Authority regulates and supervises the insurance sector in the Kingdom, having taken over from the Saudi Central Bank (SAMA) following its establishment in 2023, and having also assumed health insurance supervision from the Council of Health Insurance; SDAIA and the National Data Management Office govern data management and classification alongside the Personal Data Protection Law; the National Cybersecurity Authority sets the national control baseline; ZATCA governs tax and e-invoicing obligations; and bank-distributed or investment-linked products bring the relevant financial-sector regulation to that channel. Treat this as a map of who asks, not as a statement of what is currently required - specific obligations, ratios, templates and dates change, and under a supervisor still building out its framework they change faster than usual. They are your own compliance and actuarial functions' to confirm against the current published text, and any sector page that tells you otherwise is one you should trust less rather than more.
This page deliberately does not quantify that, because a client count on a web page is unverifiable and therefore worthless to you as evidence. The honest answer is the one you can check: ask us, in a first conversation, for engagements of a shape comparable to yours, for the named individuals who would be on your programme and what they have personally delivered in a carrier, and for a reference call with a client who will take it. We will approach a suitable client and put you in touch directly if they agree. Published work our clients have approved is on our success stories page.
There are no numbers in this section, and that is the point. The heading was drafted for a page that would publish a count of carrier clients, a number of policies migrated and a set of loss-ratio or expense-ratio improvements. We will not write figures we cannot evidence to you on request, and you have no way to tell a real one from an invented one - which is exactly why the invented ones are so common in this sector, where a claim to have cut claims leakage by a given percentage is simultaneously unfalsifiable and extremely persuasive.
More useful than our numbers is knowing which numbers to demand, of us and of everyone else bidding.
Named engagements of your shape, with the client contactable - comparable lines of business, book size and platform vintage. One reference call with the programme lead who lived through the migration is worth more than any aggregate.
The baseline behind every improvement claim - what it was measured against, over what period, who measured it, and whether the baseline was recorded before the work started or reconstructed afterwards.
What the carrier could operate afterwards without them - which capabilities transferred, who holds them now, and what the carrier has changed on its own since handover without raising a variation. In insurance the sharpest version of this question is: can your own people configure and launch a new product without calling the vendor?
The engagements that went badly, and what changed afterwards. Every firm with real core-replacement experience has ones that hurt. An adviser who cannot name one has either not done enough of this work or is not telling you about it.
The named individuals on your programme and their availability.
How the adviser is paid, and whether they will bid. We do not earn a margin on your licences; put the same question to everyone else.
Where our clients approve publication, their results appear on our success stories page with the detail they approved. That page, not this one, is where our record lives.
Organisations across several sectors in the Kingdom have engaged us on selection, architecture and assurance work. We name a client only where that client has agreed to be named for the specific purpose, and in insurance that permission is rarer and slower than elsewhere: approval runs through communications and, in a listed or group-owned carrier, through the function responsible for market disclosure, and the engagement often touches a platform decision or a supplier relationship the carrier has not announced. A logo published without a current permission is a breach of confidence dressed up as marketing.
The organisations who have agreed are on our customers page, which is maintained against those permissions rather than assembled for this page. If you would like a reference from a carrier of comparable book size or line mix, ask during a first conversation - we will approach a suitable client and put you in touch directly if they agree.
Our published project record is on the success stories page. It carries the engagements our clients have approved for publication, with the detail they approved, and that is the honest extent of what we can show a stranger on a web page. It is not a complete record, because most clients in regulated sectors do not publish, and it deliberately contains no anonymised composites - so the absence of a story matching your situation is evidence the client concerned did not agree to publish it, not evidence the work was not done. Ask us in a conversation; the constraint is publication, not disclosure to a prospective client under an appropriate agreement.
Client feedback we have permission to publish appears on our customers and success stories pages. There is no quotation written into this section, and the absence is deliberate: we do not publish a client quote until the client has reviewed and approved the exact wording attributed to them, for the specific place it will appear. A testimonial drafted by a marketing team and attributed to a job title is not evidence of anything, and a reader cannot tell one from the real thing.
If what you actually want is to hear from somebody who has been through this decision, ask for a reference call - ideally with the claims or operations lead rather than the executive sponsor, because they are the one who lived through cutover and the first reporting cycle after it.
Our current vendor relationships, accreditations and the certifications our consultants hold are published on the partners page. We keep them there rather than restating them in sector copy: partner tiers and individual certifications change, and a page asserting a status it can no longer stand behind is worse than one that does not assert it at all.
Because "is this firm qualified" is the question most often asked and least often verified, here is what we would check - about us or about anyone else bidding. Ask for the certifications of the named individuals who will be on your programme rather than the firm's aggregate status. Ask who on the team has personally delivered a core insurance platform, which is materially different from delivering enterprise software generally. Ask for a reference from an engagement of comparable complexity, ideally one that went less than smoothly, and ask what was done about it. Ask how the commercial relationship works - whether the firm earns on the licence or the implementation as well as the advice, and whether it intends to bid for the work it is scoping. And ask what handover looks like, and what your own people would be able to change afterwards without calling anyone.
A first conversation is an hour with people who have done this work, not a sales presentation. Bring the decision you are facing and the constraint you think you are under; we will tell you where we think the real constraint is, what we would want to see before advising properly, and whether this is work we are the right firm for. Sometimes it is not, and saying so early is cheaper for both of us than discovering it in a proposal.
If a procurement is already in motion, say so at the start. It is also a fair opportunity to test us on everything this page has asked you to demand of an adviser - the named individuals, the reference call, the engagement that went badly, what capability you would be left with, and how we are paid.
Request an advisory call, or ask us for a reference from a carrier of comparable book size before you commit to anything.