Insurance Software Development
By Ashiqur Rahman
Insurance software development is worth paying for when a packaged core system cannot meet a deadline a statute sets. Omega Solution’s AI claims assistant for Claim Central took four people five weeks, about 800 hours. One page on this whole subject publishes an hourly rate, and its own totals do not reconcile with it.
This guide is built around that gap between what the category claims and what it can show. It starts with what insurance software development covers, what InsurTech actually means, and why insurers commission custom work in 2026. It then sets out what Omega Solution builds, how a build runs, and one delivered project with its team and duration published. After that come the numbers: what manual claims handling really costs against the clocks each state writes into law, what claims automation with AI can and cannot do, what claims software costs to buy and to build, and how core banking splits between custom and packaged. It closes with compliance, how to judge a development partner, and the four mistakes that cost insurers most.
What Insurance Software Development Covers
Insurance software development means building systems carriers, brokers, and third-party administrators cannot buy off the shelf: claims intake and adjudication, policy administration, rating and quoting, agent portals, and the integrations between them. The packaged alternatives exist and are mature. Custom work earns its place when a statutory deadline, a line of business, or an integration doesn’t fit.
The category divides into four layers, and only the fourth is usually worth building from scratch.
| Layer | What it does | Buy or build |
|---|---|---|
| Policy administration | Quote, bind, issue, endorse, renew, cancel | Buy. Guidewire, Duck Creek, Majesco and others own this |
| Claims management | FNOL, assignment, reserves, payments, recovery, reporting | Buy for standard lines. Build where the line of business is unusual |
| Agency and broker management | Clients, policies, commissions, certificates, documents | Buy. Priced per seat, though almost no vendor publishes the rate; see the cost section below |
| Decision, automation and integration layers | Document understanding, triage, statutory clock enforcement, the joins between the above and finance | Build. No catalogue product fits one carrier’s rules |
Omega Solution’s own insurance business is located in the fourth row, which is also the layer that the ranking pages mention the least. None of the five agency service pages on page one for this topic publish an hourly fee, two do not publish any dollar value at all, and none publish an hours figure.
Why the buy decision usually comes first
A packaged core system is the right answer for most carriers most of the time, and any development partner that never says so is selling rather than advising. The question is not whether Guidewire or Duck Creek works. It is whether the twenty percent of your process that does not fit them is worth building around, and what that twenty percent costs in adjuster hours and statutory exposure while it stays manual.
What Is InsurTech
InsurTech is the use of software, data and automation to change how insurance is distributed, underwritten, priced and settled, rather than simply digitising paper. The term covers full-stack digital carriers, distribution platforms, and the tools incumbents buy. For a development agency, the useful split is between products that hold risk and products that handle work.
An insurer is Risk-holding InsurTech. It requires funding, reserves, files, licenses in each state where it writes, and statutory reporting. Although software is essential, it is not the difficult part, and no organization should suggest otherwise.
Work-handling InsurTech is software sold to carriers, brokers, adjusters or policyholders. It needs no insurance license, it ships in weeks rather than years, and it is almost always where a software partner can help. Omega Solution’s Claim Central AI build is this kind: a tool that reads a policy and produces a claim letter, not a product that pays claims.
What the definitional pages leave out
Page one for this question holds no development agency at all. It holds a Salesforce product page, two vendor blogs, a reinsurance trade association, a trade publication, a recruiter’s blog and an encyclopedia entry. The winner runs about 1,800 words; the thinnest ranking page runs about 420 and names no author, no organization and no date.
What none of them covers is the regulatory line between the two kinds of InsurTech, which is the first question any founder building in this space has to answer. That line decides whether the project is a software build or a licensing program with software attached.
Why Insurers Commission Custom Software in 2026
Three forces push insurers into custom work: statutory claims clocks that packaged workflows do not always enforce, AI governance rules that arrive faster than core system roadmaps, and integration debt between systems bought in different decades. The deadlines are not aspirational. Texas attaches an 18% penalty and attorney’s fees to missing one.
The clocks are in statute, not in the vendor’s workflow
One nationwide workflow is flawed somewhere since each state sets its own timeframes for processing claims. Four states are shown side by side in the section on manual claims that follows. The instant a carrier writes in a second state, a packaged system that was initially built for a single-state carrier becomes a compliance issue.
AI governance arrived before the core systems were ready
The NAIC adopted its Model Bulletin on the Use of Artificial Intelligence Systems by Insurers on 4 December 2023, and it expects every insurer to develop, implement, and maintain a written program (an ‘AIS Program’). Colorado, New York and the EU each added their own requirements on top. Those obligations attach to models already in production, not to the next release of a vendor platform.
Integration debt compounds quietly
Carriers accumulate a policy system, a claims system, a billing system, a document store and a general ledger, bought years apart, and staff become the integration between them. That work never appears on an invoice, which is why it survives for years and why an integration layer is usually a far smaller build than any replacement.
The buy option is genuinely opaque
Of the claims and agency software vendors Omega Solution checked, ten publish no price at all, and Five Sigma states it will price on “claim volume, lines of business, and the capabilities you need” without publishing a rate for any of those units. When buying cannot be budgeted without a sales cycle, building stops looking unreasonable by comparison. The full list is in the section on claims software cost below.
What Omega Solution Builds for Insurers and Banks
Omega Solution builds four things in this sector: document and decision layers that read policies and claims, automation that enforces statutory clocks, integration layers between systems already bought, and customer-facing portals and apps. All of it ships under custom software development, with scoping first and support after launch.
Document and decision layers
The largest category and the one with the clearest case for building. Policy interpretation, coverage identification, claim letter generation, document classification, and triage that routes a file by what is in it rather than by who is free. The case study below is exactly this shape.
Statutory clock automation
Acknowledgement, decision and payment deadlines applied per state, per line, with the status letters each state requires on its own cadence, and an audit trail that survives a market conduct examination. This is the module most worth building because no packaged configuration covers every state a growing carrier writes in.
Integration layers
A service that maintains consistency between the general ledger, claims system, and policy system. It eliminates the re-keying that results in the reporting inaccuracies discovered at quarter’s end and is far smaller than replacing any of them.
Portals, apps and agent tools
Policyholder self-service, FNOL capture, adjuster field tools and broker portals, where the work happens away from a desk.
Alongside the build, Omega Solution offers IT consultation for the scoping and buy-or-build decision, MVP development where a carrier wants to prove a workflow before committing, AI and automation for document and exception handling, team augmentation where an insurer already has engineers, and maintenance and support afterwards. Anything outside that list is not something to expect from this page. Omega Solution is not an insurance licensing consultancy and does not file rates or forms.
How Omega Solution Runs an Insurance Build
Omega Solution runs an insurance build in five steps: IT consultation, process and clock mapping, architecture with the buy-or-build decision, development, then maintenance and support. The Claim Central AI build ran that sequence in five weeks with four people. The timeframes below describe that project, not a promise that every build matches it.
Step 1: consultation
What the carrier is trying to change, which systems exist, who touches each file, and where the manual work sits. The output is a written problem statement, not a proposal.
Step 2: process and clock mapping
Each process is followed end to end, and every statutory deadline it touches is written down per state and per line. This is where scope usually shrinks, because a mapped process shows which parts the packaged system already handles correctly.
Step 3: architecture and the buy-or-build decision
The scope splits in two: what gets built and what stays bought, with the bought products named. A carrier should expect to be told to keep paying a vendor where that is cheaper.
Step 4: development
Each role is listed with its headcount, and the weeks it works, so the total can be rebuilt from its parts. Claim Central AI ran for five weeks with one developer on the front end, one on the back end, plus DevOps and project management.
Step 5: maintenance and support
Priced as its own line rather than folded into the build, and in this sector it carries a governance component: models in production need the monitoring and documentation the NAIC bulletin and the New York circular both expect.
Case Study: An AI Claims Assistant Built in Five Weeks
Claim Central is a US InsurTech. In 2025 Omega Solution built an AI claims assistant that reads a policy, interprets coverage and produces a claim letter in five weeks with a team of four. The case study page publishes three outcome figures: 93% faster claim processing, $2.4 million saved and more than 12,000 claims processed.
It separately claims over 96% accuracy in coverage identification, but that sits in the feature list rather than the results, so it is a product claim and not a measured outcome. The distinction matters on a page arguing that this category does not separate the two.
The stack is React and Laravel with the Gemini API as the analytical engine, and the design is deliberately hybrid: AI output is verified by human experts rather than published straight to the user. The engagement is described on Omega Solution’s own Upwork work history as AI-Powered MVP Development for Insurance Application, which is the honest frame for a five-week build. The delivered features, as listed on the Claim Central AI case study, are instant policy review and interpretation, claim letter generation, personalized guidance, expert review, and a three-step flow from policy upload to finished letter.
Omega Solution scores the page against the five tests it applies to every case study it reviews.
| Test | Claim Central AI | Result |
|---|---|---|
| 1. Client named | Claim Central, USA, 2025 | Pass |
| 2. Before and after, in numbers | Three outcome figures published (93% faster, $2.4m, 12,000+ claims) but no baseline for the percentage. The 96% sits in the feature list, not the results | Fail |
| 3. Team size or duration | 4 people, 5 weeks | Pass |
| 4. Project cost or budget | Not published | Fail |
| 5. A named person with a title | A named review is published, but the reviewer’s stated employer differs from the client, so it is not relied on here | Fail |
Two out of five, and the aim is to publish. No development agency case study had a score higher than three out of five, and none of the six results pages examined for this guide included a project cost. The previous cycle time behind the 93% is one baseline figure on this page that would raise it to three. If the budget is released, it will be the only case study Omega Solution with a project cost in this industry.
What 800 hours buys, and what it does not
The case study page lists the team as one front-end developer, one back-end developer, one DevOps engineer and one project manager, and the duration as five weeks. Four people at 40 hours a week is at most 800 hours. That is a ceiling rather than a timesheet, since a project manager and a DevOps engineer are rarely billed full time for every week.
Set that against the only page in the census that publishes both hours and a rate. Itexus states that, on average, claims management software development from scratch will cost from 1,130 to 3,000 hours depending on the number of features, and that At Itexus, we apply a 35-40 per hour rate to Fintech projects. At those rates, 800 hours comes to $28,000 to $32,000.
The comparison is honest only with the difference stated: Claim Central AI is a claims assistant, not a claims management system. It reads policies and drafts letters. It does not hold reserves, issue payments or produce statutory reports. That is precisely why it came in below Itexus’s 1,130-hour floor, and a carrier pricing a full claims platform should expect Itexus’s range, not this one.
Why Manual Claims Processing Costs More Than It Saves
Manual claims processing costs more than it saves because the deadlines are statutory, not internal. California gives 40 calendar days to accept or deny after proof of claim; New York 15 business days, Minnesota 30 business days. Texas adds 18% interest and attorney’s fees for missing its clock. No ranking page on this subject cites any of them.
The clocks, as the statutes write them
| State | Acknowledge | Accept or deny | Pay after agreement | Written into |
|---|---|---|---|---|
| California | No event more than fifteen (15) calendar days after receipt | No event more than forty (40) calendar days later | No event more than thirty (30) calendar days later | 10 CCR 2695.5, 10 CCR 2695.7 |
| New York | Within 15 business days, acknowledge the receipt of such notice (216.4) | Within 15 business days after receipt by the insurer of a properly executed proof of loss | Not later than five business days from the receipt of such agreement | 11 NYCRR 216.6 for the last three |
| Texas | Not later than the 15th day… after the date an insurer receives notice of a claim (§ 542.055(a)) | 15 business days after receiving all requested items (§ 542.056(a)), extendable by 45 days (§ 542.056(d)) | 5 business days after notice of acceptance (§ 542.057(a)) | Tex. Ins. Code § 542.055. Penalty under § 542.060 |
| Minnesota | Within ten business days | Within 30 business days after receipt, unless the investigation cannot be reasonably completed within that time | Advise within 60 business days of proof of loss | Minn. Stat. § 72A.201, framed as prohibited practices rather than affirmative deadlines |
California’s status letters run every thirty (30) calendar days; New York’s run at 90 days from the date of the initial letter. and every 90 days thereafter. A single national reminder cadence is wrong in at least one of those two.
The NAIC model does not contain the deadlines
This surprises people who assume a national floor exists. The NAIC Unfair Claims Settlement Practices Act, Model #900 sets no acknowledgement, decision or payment day count at all. It requires only that insurers not fail “to acknowledge with reasonable promptness pertinent communications”, plus a fifteen calendar day rule for providing claim forms. Every hard clock a claims system enforces comes from state law, which is why the enforcement logic has to be configurable per state rather than hard-coded once.
Nobody publishes the number the whole industry quotes
n2uitive, the one page on this results set that quantifies the delay, says manual handling leads to an average delay of 7-10 days” and cites nothing. Omega Solution went looking for an official figure, and there is not one.
Claims closed with payment within 0 to 30 days, 31 to 60, 61 to 90, 91 to 180, 181 to 365, and beyond 365 are all included in the NAIC’s Market Conduct Annual Statement. The ratio definition “Percentage of claims paid beyond 60 days” is published. The NAIC does not release a national average or median cycle time, and the company-level data behind it is regulator-confidential. Therefore, a carrier should measure its own, and any particular day count in marketing materials for this category is not an official statistic.
That MCAS ratio is the useful one to build toward, because it is the measure a regulator already applies to you.
Where the days actually go
- Intake. A first notice captured on a phone call and typed into a form later is the single largest source of the documentation gaps that cause downstream denial.
- Document handling. Policy documents, estimates and invoices arriving as email attachments and scans, classified by hand.
- Coverage interpretation. An adjuster reading a policy to answer a question the policy answers the same way every time.
- Routing. Files assigned by availability rather than by complexity, so the hard ones wait behind the easy ones.
- Status letters. A statutory obligation handled by diary entries, which is where multi-state carriers miss deadlines.
Only the first and the last cost money directly. The middle three cost adjuster hours, which is the number a carrier can measure without any vendor’s help.
Claims Automation With AI
Claims automation with AI means using models to read documents, extract fields, classify and triage files, and draft correspondence, with human review on anything that decides coverage or payment. It works well on document understanding and routing. It is governed, as of now, by at least three separate regimes, and it does not replace an adjuster’s judgment on coverage.
What the technology is genuinely good at
Document understanding is the mature part. Reading a policy, pulling the coverages, classifying an incoming file and drafting a first response are tasks with verifiable outputs, which is why Claim Central AI was built around exactly those and kept expert verification on the result.
Straight-through processing is where claims about automation get loose. The ranking pages disagree with each other on the current rate: Lido says most carriers achieve STP rates of 15-30% of total claim volume; VCA Software says industry-wide, P&C STP rates average below 10%. Leading carriers reach 35% on eligible claim types. Those cannot both describe the same quantity. Neither cites a source.
The number everybody repeats
A 30% reduction in claims cost appears on four separate pages in this census. Noxus attributes it to McKinsey, Kognitos gives a 20% version attributed to BCG, and Itexus and n2uitive state it bare with no source at all. Treat it as an industry convention rather than a benchmark, and ask any vendor quoting it which carriers, which lines and what baseline.
Insurance fraud is worse, because the three figures in circulation are not estimates of the same thing. ScienceSoft cites the FBI for more than $40 billion annually; Indico says fraud costs more than $300 billion per year in the U.S. alone; n2uitive gives $308.6 billion annually with no source at all.
Put each against the scope its own publisher gives it. The Insurance Information Institute handbook, reporting an undated FBI figure, records that the FBI reports that the non-health insurance portion of the overall problem amounts to $40 billion annually, and separately an undated NHCAA figure that the National Health Care Anti-Fraud Association (NHCAA) estimates that the financial losses due to health care fraud are $68 billion, or as high as $300 billion. The NAIC says something narrower again: that fraud costs consumers $308.6 billion a year, crediting the Coalition Against Insurance Fraud and naming neither a study nor a year.
That is three organizations, three methodologies and three undated figures, measuring three different things: non-health only, health only, and a cost borne by consumers. They do not reconcile, and resist the temptation to add the first two together to reach the third. Do the arithmetic and it falls apart: $40 billion plus $300 billion is $340 billion, which overshoots by a tenth, and taking the NHCAA floor instead gives $108 billion, barely a third of it. Run the decomposition the other way and the two are further apart still.
The honest conclusion needs no arithmetic at all. None of the three figures carries a date, a method or a defined scope that a reader can check, and a carrier sizing its own fraud exposure from any of them is sizing something it has not defined.
What governs a model once it is in production
| Regime | What it requires | Status as of 4 October 2026 |
|---|---|---|
| NAIC Model Bulletin on AI | A written AIS Program; due diligence on third-party data and systems; answers at market conduct exam | Adopted 4 December 2023. The NAIC’s implementation map dated 1 April 2026 lists adopting jurisdictions by name and prints no total |
| Colorado, Reg 10-1-1 under SB21-169 | A risk-based governance and risk management framework for external consumer data and the models using it, and a description of quantitative testing under § 5.A.11 | Amended regulation effective 15 October 2025. No testing methodology has been adopted, so the reporting requirement is waived for the current reporting period only |
| NYDFS Circular Letter No. 7 | Unfair or unlawful discrimination testing and analysis should be administered prior to putting AIS into production and on a regular cadence thereafter, as well as whenever material updates or changes are made to either the ECDIS or AIS; insurers retain responsibility for third-party vendor tools and data | Issued 11 July 2024 |
| EU AI Act, Annex III point 5(c) | EIOPA states that the AI Act identifies as high-risk the use of AI systems for risk assessment and pricing in relation to natural persons in the case of life and health insurance | Application was to begin 2 August 2026. Regulation (EU) 2026/1744 of 8 July 2026, the Digital Omnibus on AI, moved it: Recital 40 sets the date to 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I |
Two corrections worth carrying, because published guidance commonly gets both wrong.
Colorado is usually described as requiring quantitative testing. The requirement to describe testing is in § 5.A.11 of the amended Regulation 10-1-1 effective 15 October 2025, and the section number moves between rule versions, so pin the version when citing it. No methodology has been adopted to test against. Revised Bulletin B-10.004, issued 18 October 2024 and reissued 22 October 2025, states the causal condition and the consequence in one sentence: Because the Division has not yet adopted a regulation establishing the required quantitative testing referenced in Regulation 10-1-1, the quantitative testing reporting requirement is not applicable for the current reporting period. Two draft regulations are posted, and neither is adopted.
The relief is temporary, not permanent. It covers the annual reports due 1 December 2024 and 1 December 2025, and the bulletin states that “subsequent annual reports will be expected to include a description of the quantitative testing conducted.” A carrier building governance tooling for Colorado should build for the requirement, not for the waiver.
The majority of published literature still prints August 2, 2026, which is no longer the EU high-risk deadline. According to Recital 40 of Regulation (EU) 2026/1744, it is appropriate that the date of application of Sections 1, 2 and 3 of Chapter III is set to 2 December 2027 for AI systems classified as high-risk pursuant to Article 6(2) and Annex III, and to 2 August 2028 for AI systems classified as high-risk pursuant to Article 6(1) and Annex I. The Commission’s 2025 proposal contained the conditional, standards-dependent trigger, but it was not included in the final version.
Claims Management Software Cost
Insurance claims software cost is the hardest figure in this sector to get, because the vendors who sell it mostly decline to publish one. Of the claims platforms Omega Solution checked, Guidewire, Duck Creek, Five Sigma, Snapsheet, Insurity, Origami Risk and ClaimVantage publish no price. Not one vendor anywhere publishes a per-claim rate.
What the category actually publishes
Snapsheet says cost can vary based on several factors, including the size of your organization. The number of claims you manage, and the level of configuration needed, then offers a customized quote. AgencyBloc prices one module on volume of transactions and another on volume of groups quoted, with no figure against either. The pattern is consistent: the units are named, the rates are not.
The exceptions are at the agency management end, and even there the published figures are for add-ons and services rather than the platform itself.
| Vendor | Published price | Unit |
|---|---|---|
| HawkSoft e-signature | $39.00/license | per license per month |
| HawkSoft services | $150.00/hour | per hour, with one- and two hour minimums |
Why that matters for a buy-versus-build comparison
The build side of this decision can be stated in hours. The buy side cannot be stated at all until a sales process finishes, and no vendor anywhere in this census publishes a per-claim, per-policy or per-adjuster price. A carrier asking for both numbers on the same day will get one of them.
HawkSoft’s hourly minimums
HawkSoft publishes $150.00 an hour for consulting, data work, custom programming and training, with a two-hour minimum on most of those and one hour on after-hours support and accounting clean-up. Local travel is billed separately at $60.00 an hour. A 30-minute training session therefore bills $300, an effective $600 an hour, four times the headline rate. The minimum stops binding at exactly two hours.
What building costs instead
Two pages on these results publish figures a reader can test, and they imply hourly rates four to six times apart.
ScienceSoft states that From ScienceSoft’s experience, the cost of insurance software development services may range from $120,000–$180,000 for building a mobile insurance app of average complexity to $1,000,000–4,000,000+ for engineering a large-scale insurance automation system powered by AI technology, and publishes no hours and no rate. Applied to an 800-hour project like Claim Central AI, that floor implies $150 to $225 an hour. Itexus publishes $35 to $40. DOOR3 publishes only a floor: our minimum engagement costs sit around $25k.
Itexus is also the only page that can be checked against itself, and it does not reconcile. Its hours range is 1,130 to 3,000, and its stated rate is $35 to $40, which multiplies out to $39,550 to $120,000. The page’s own stated total is $45K – $63,500 and $150,000 at $50 an hour, which implies 1,270 to 3,000 hours rather than 1,130 to 3,000. Three statements, three different hour bases. The multiplication is Omega Solution’s; the inputs are all Itexus’s.
That is the whole argument for asking any vendor for hours, roles and a rate rather than a band. A band cannot be checked. Hours times a rate can.
Core Banking: Custom vs Packaged
A core banking software comparison almost always ends in buy, not build. The ledger, the regulatory reporting and the payment rails are commodity infrastructure with severe consequences for error, and no major core vendor publishes a price anyway. What is worth building sits above the core: origination, onboarding, servicing portals and orchestration.
Nobody at the core end publishes a price
Temenos, Finastra, FIS, Fiserv, Jack Henry, Mambu, Thought Machine, Tuum, 10x Banking, nCino and Backbase publish no platform price. Backbase states it plainly: Subscription-based licensing. Contact Backbase for a custom quote. That opacity is itself a planning problem, because a buy-versus-build comparison needs one of the two numbers, and this side will not supply it.
The layer above the core does publish
Banking-as-a-service and payment API providers publish real per-unit prices, which makes the orchestration layer the one part of a banking stack a buyer can model in a spreadsheet before talking to anyone. Increase publishes $0.50/transaction for next day ACH origination and $15.00/transaction for wires. Moov publishes 25¢ per transaction for next-day ACH credits against a $500 monthly minimum. Those two facts alone decide which provider is cheaper at a given volume: $0.50V = $500 at V = 1,000 transfers a month, so Increase is cheaper below that and Moov above it. That arithmetic is Omega Solution’s, from the two published rate cards.
Where this leaves an insurance pillar
Core banking is a different buying centre from claims and policy software, and it deserves its own page rather than a corner of this one. The short version for anyone arriving here from an insurance question: buy the core, build the orchestration and the customer-facing layers, and judge any provider by whether it publishes a unit price you can multiply.
What Compliance Adds to an Insurance or Banking Build
Compliance adds four things to a build in this sector: statutory claims clocks, AI governance documentation, incident reporting on a 36-hour deadline, and third-party risk obligations the carrier or bank cannot delegate to its vendor. Two of the standards most often quoted as current were replaced in 2026.
The incident clock is 36 hours, and the service provider’s is immediate
Under 12 CFR 225.302, a banking organization must notify its regulator “as soon as possible and no later than 36 hours after the banking organization determines that a notification incident has occurred”. The parallel OCC rule is 12 CFR 53.3.
The part that lands on a software partner is 12 CFR 53.4(a). It requires a bank service provider to notify each affected bank customer as soon as possible, and the four hours in the rule is not a deadline: it is the materiality threshold on the disruption, which must have materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, covered services provided to such banking organization for four or more hours. Read it the other way round, as a four-hour notification clock, and the obligation is both later and looser than the rule actually is. Any team building and operating software for a bank should have that notification path written into the contract and the runbook before launch.
Model risk guidance changed in 2026
Most published material still cites SR 11-7 and OCC Bulletin 2011-12 as the model risk standard. Both have been replaced. The Federal Reserve issued SR 26-2, “Revised Guidance on Model Risk Management”, on 17 April 2026, and the OCC now hosts Bulletin 2011-12 under its rescinded bulletins, replaced by OCC Bulletin 2026-13.
SR 26-2 is also explicit about its own force: This guidance does not set forth enforceable standards or prescriptive requirements; accordingly, non-compliance with this guidance will not result in supervisory criticism against a banking organisation. That is a materially different framing from how SR 11-7 is usually presented, and anyone citing the old letter as a hard requirement is citing a rescinded document.
Third-party risk does not transfer
The 2023 Interagency Guidance on Third-Party Relationships states the principle a vendor cannot argue away: A banking organization’s use of third parties does not diminish its responsibility to meet these requirements to the same extent as if its activities were performed by the banking organization in-house. The NYDFS circular says the same for insurers: they retain responsibility for understanding the tools, external data and AI systems used in underwriting and pricing that were developed or deployed by third-party vendors, and for ensuring those comply with applicable law.
Worth tracking rather than relying on: the agencies published proposed guidance on 15 September 2026 to rescind and replace existing guidance on third-party risk management, with comments due 16 November 2026. The 2023 guidance has not been rescinded.
Payment rails moved, and the published dates are often stale
| Item | Current fact | Commonly miscited as |
|---|---|---|
| Fedwire ISO 20022 | The implementation of ISO 20022 on July 14, 2025, per the Fedwire ISO 20022 FAQ; completion announced 15 July 2025 | 10 March 2025, the originally announced date in 87 FR 64217 |
| CHIPS ISO 20022 | Migrated on the 8 April 2024 banking day, per The Clearing House | various |
| FedNow customer credit transfer limit | $10 million since 12 November 2025, up from $1 million | $500,000 or $1 million |
| FedNow participation | More than 1,800 financial institutions are now live, 15 July 2026 | various |
This guide summarises rules as published on 4 October 2026. It is not legal advice, and any build encoding these requirements should have them confirmed by counsel and by the institution’s compliance function.
How to Evaluate an Insurance Software Development Partner
Judge a partner on what it will put in writing. Of the five agency service pages ranking on page one for this subject, none carries an author byline or a named technical reviewer, none publishes an hours figure, and two publish any dollar figure. Five questions separate a quote that can be checked from one that cannot.
How many hours, from which roles, over how many weeks?
A total with no hours behind it cannot be verified. The one page in this census that published both hours and a rate could not reproduce its own total from them. Any agency can answer this, and almost none do.
What would you recommend against building?
A partner whose scope only grows is selling rather than advising. In this sector the honest answer usually includes the policy core and the ledger.
Which statute does this module enforce, by section?
Only one page in the entire census cited anything by section number. For software whose job is to meet deadlines written into state regulation, a partner who cannot name 10 CCR 2695.7 or 11 NYCRR 216.6 has not read the requirement being automated.
What outcome numbers do your case studies carry, and against what baseline?
Outcome percentages are published freely in this sector. Baselines are not. Of the 22 case studies Omega Solution scored across these results, three published a genuine before-and-after pair, and none published a project cost. Omega Solution’s own case study fails the baseline test, which is stated plainly above rather than hidden.
Who reviewed this for accuracy, by name?
Not one agency page on these results names a separate technical reviewer. For software encoding claims law and AI governance, a named compliance officer, actuary or counsel would be unique in this vertical.
One caveat stated against Omega Solution’s own interest: the largest firms on this results set carry decades of carrier implementations and name clients such as AIG, Generali and UNIQA. Omega Solution has one published insurance client. A buyer weighting portfolio depth above everything should factor that in.
Four Mistakes Insurers Make When Commissioning Software
Four mistakes cost insurers the most: rebuilding the policy core, hard-coding one state’s claims clock, buying an AI feature without the governance program behind it, and treating a vendor as the compliance owner. Each has a source in the sections above.
Mistake 1: rebuilding the policy core
Policy administration is mature, crowded and dangerous to rebuild. The case for custom work sits in the decision and integration layers, where no catalog product fits one carrier’s rules.
Mistake 2: one clock for every state
The four states in the table above run on four different clocks, and their status letter cadences differ again. A single configured deadline is wrong the moment a carrier writes in a second state, and under Texas Insurance Code § 542.060 the error carries 18% interest and attorney’s fees, except where § 542.060(c) substitutes a rate five percentage points above the Finance Code § 304.003 rate.
Mistake 3: buying the model without the program
The NAIC bulletin expects a written AIS Program; New York expects discrimination testing before production, on a regular cadence after it, and whenever the data or the system materially changes, and Colorado expects a documented governance framework. A model delivered without that documentation is a finding waiting for the next market conduct examination.
Mistake 4: assuming the vendor carries the risk
The interagency guidance and the NYDFS circular both say the opposite in plain words. Responsibility stays with the institution, which means the build has to produce the evidence the institution will be asked for, not just the feature.
Frequently Asked Questions
What is insurance software development?
It is building systems carriers, brokers, and administrators cannot buy off the shelf: claims decision and document layers, statutory clock automation, integration between policy, claims and finance systems, and customer-facing portals. Policy administration and core ledgers are normally bought, because those categories are mature and crowded.
How much does insurance software development cost?
Published figures range from a $25,000 minimum engagement to $4 million or more, and almost none derive from hours. Omega Solution’s AI claims assistant took about 800 hours, which at the only hourly rate published anywhere in these results, $35 to $40, is $28,000 to $32,000. Ask for hours and a rate.
What is InsurTech?
InsurTech is software, data and automation applied to how insurance is distributed, underwritten, priced and settled. It splits into risk-holding products, which need capital and state licenses and are insurance companies, and work-handling products sold to carriers, brokers and policyholders, which need neither and ship far faster.
How much does insurance claims software cost?
Most vendors do not say. Guidewire, Duck Creek, Five Sigma, Snapsheet, Insurity and Origami Risk publish no price, and no vendor publishes a per-claim rate. HawkSoft publishes $150 an hour for services and $39 a license for e-signature, but not a platform price. Build cost, by contrast, can be stated in hours.
What is insurance claims automation?
It is the use of models on the parts of a claim that are text: classifying an incoming file, pulling fields out of documents, routing by content, and drafting a first response, with a person deciding coverage and payment. Document work is the mature part. Ranking pages put the industry rate at both below 10% and 15 to 30%.
Should we build or buy core banking software?
Buy the core. The ledger, regulatory reporting and payment rails are commodity infrastructure with severe consequences for error, and no major core vendor publishes a price anyway. Build the layers above it, where requirements are institution-specific and the underlying per-transaction costs are published by providers such as Increase and Moov.
How long does an insurance software build take?
Omega Solution delivered the Claim Central AI assistant in five weeks with four people: front end, back end, DevOps and project management. That is at most about 800 hours. A full claims management platform is a different order of work; the one-page publishing hours for that puts it at 1,130 to 3,000.
Does the EU AI Act apply to insurance pricing?
Yes, for life and health. EIOPA states the AI Act treats risk assessment and pricing of natural persons in life and health insurance as high-risk under Annex III. Regulation (EU) 2026/1744 of 8 July 2026 moved the start date from 2 August 2026 to a fixed 2 December 2027.
Planning an insurance or banking build and want the hours scoped before the price? Start with an Omega Solution IT consultation, or see the full custom software development service.
Aug 26, 2025
Dhaka, Bangladesh
