The popular advice is simple: choose the biggest technology partner and let its scale solve claims complexity. That advice fails too often in insurance. Scale can provide resilience, integration expertise, and managed operations, but it doesn't automatically produce fast, focused claims automation. For buyers assessing DXC Technology in 2026, the harder question is whether its AI and insurance investments are durable enough to justify long-term dependence, or whether a layered architecture is safer.

DXC was created through a major IT-services consolidation. Hewlett Packard Enterprise spun off its Enterprise Services business on March 31, 2017, and the merger with Computer Sciences Corporation closed on April 1, 2017, creating DXC as a standalone company, as documented in its fiscal 2017 annual report. That history explains both the company's enterprise reach and the complexity buyers must evaluate beneath its modernization narrative.

Why Large IT Services Firms Struggle with Claims Automation

Large IT services firms often present themselves as end-to-end transformation partners. The assumption is that a provider with broad consulting, systems integration, cloud, and managed-services capabilities will also deliver the fastest claims automation. That inference isn't reliable. A company can be excellent at operating complex environments while remaining slower at releasing narrowly focused workflow capabilities.

Claims teams need automation that responds to changing document types, routing rules, authority thresholds, and handler feedback. They also need clean integration with systems that weren't designed as modern, event-driven platforms. A large provider may be able to manage those dependencies, but its delivery model can favor lengthy programs, extensive governance, and customized service arrangements over rapid product iteration.

Scale isn't the same as product maturity

The useful distinction is between operational scale and claims-product maturity. Operational scale means a provider can run infrastructure, support distributed users, manage security controls, and coordinate large transformation programs. Product maturity means claims staff can configure workflows, test decision logic, observe model outcomes, and receive improvements without turning each change into a professional-services engagement.

Buyers should test four areas:

• Workflow depth: Does automation cover intake, document handling, triage, follow-up, and settlement support, or only selected steps?

• Integration behavior: Can the platform exchange structured data with policy, claims, payment, and reporting systems without creating duplicate records?

• Iteration speed: Can business users refine rules and exceptions through governed configuration?

• Evidence quality: Can the vendor demonstrate auditability, human review, and production controls rather than relying on AI language alone?

DXC has demonstrated substantial modernization engineering. Its AWS-based mainframe DevSecOps platform uses a single-VPC software-as-a-service architecture with Amazon AppStream 2.0, Amazon EC2, Amazon RDS for PostgreSQL, and Amazon S3, according to AWS's technical description of the platform. That supports a credible argument for enterprise architecture competence. It doesn't, by itself, prove that a claims handler receives the focused automation experience required for high-volume operations.

Practical rule: Treat “end-to-end” as a design claim to validate, not as evidence that every workflow is productized.

Teams assessing legacy dependencies can also use legacy system modernization strategies as a useful architectural lens. The central issue is not whether DXC can connect old and new systems. It is whether the resulting operating model preserves modularity, measurable ownership, and enough flexibility for claims teams to improve individual processes without reopening the entire transformation program.

DXC Technology Insurance Platform Capabilities Explained

DXC's insurance proposition should be evaluated as an ecosystem rather than a single claims application. The company's Assure portfolio and newer Assure Smart Apps are positioned around modernization and workflow support, while DXC's broader services model supplies implementation, integration, and ongoing operations. Public material describes the newer Smart Apps as agentic AI and workflow modules intended to help insurers modernize without a rip-and-replace program, according to DXC's announcement on Assure Smart Apps.

That positioning is attractive for insurers with entrenched policy and claims estates. The practical buyer question is narrower: which capabilities operate as reusable product functions, and which depend on DXC-led configuration and managed delivery?

Capability assessment

The table highlights a recurring issue in large platforms. Integration strength can coexist with integration dependency. A provider may connect many systems effectively, while the customer still needs DXC specialists to change workflows, adjust interfaces, or govern releases.

What buyers should verify

A serious evaluation should trace a claim from first notice of loss through document ingestion, coverage assessment, triage, handler activity, payment recommendation, and reporting. Ask the vendor to show where structured data is created, where it is stored, and how an exception returns to a human queue. Ask whether an insurer can inspect decision history without opening a separate investigation across service tickets, logs, and bespoke middleware.

Buyers should also distinguish between workflow assistance and claims decision automation. The former may route work, surface information, or coordinate tasks. The latter requires stronger controls around explainability, authority, evidence, and human approval. DXC's insurance portfolio may be a sensible foundation for modernization, but insurers should avoid treating the AI label as proof of complete lifecycle automation. A broader comparison of platform design patterns appears in this analysis of digital insurance platforms.

Claims Operations for Lloyd's Market Participants

Lloyd's claims operations introduce governance requirements that generic insurance modernization programs can underestimate. Managing agents, coverholders, and delegated claims administrators operate within relationships defined by authority, audit, evidence, and market-specific accountability. A platform that performs well for a centrally administered carrier may still need substantial adaptation for delegated chains.

DXC's enterprise-services model can fit organizations that need integration, infrastructure management, and operational support across complex estates. It is less clear that a broad platform alone resolves the specialist work at the edge of the Lloyd's market, particularly where claims arrive through delegated arrangements and handlers must distinguish authority, documentation, and escalation conditions.

Where Lloyd's controls change the design

Lloyd's requires a formal report to the managing agent after a delegated authority audit. Findings and recommendations are recorded in DAM under the relevant audit assignment, the managing agent reviews them and provides feedback and timelines through a DAM task, and the coverholder or DCA responds with supporting evidence through its DAM portal to close recommendations, according to Lloyd's delegated authorities audit guidance.

Claims authority creates another control boundary. Managing agents aren't permitted to appoint a delegated claims administrator to determine claims unless Lloyd's has approved that DCA. Lloyd's guidance says the managing agent should check the Insights Hub for approval status and the trading address under which the DCA is approved, as set out in the market guidance for delegated claims administrators.

The operating comparison is therefore precise:

• Managing agents: Need oversight, audit evidence, authority governance, and consistent reporting across delegated relationships.

• Coverholders: Need efficient intake, clear thresholds, evidence submission, and rapid responses to recommendations.

• DCAs: Need controlled claims determination, approved operating scope, and traceable activity.

• Brokers: Need reliable communication and visibility across parties without creating conflicting records.

Market guidance emphasizes a common audit scope, refreshed claims controls, and technical file testing, including a DCA-specific version with the same claims controls and testing, according to Lloyd's market best-practice guidance.

For this environment, DXC can provide the enterprise backbone, but buyers should test real-time delegated visibility, low-complexity triage, authority checking, and evidence capture as separate capabilities. The Lloyd's market insurance operating model is a useful reference point for that evaluation.

Evaluating Vendor Stability and Investment Capacity

Insurance buyers shouldn't evaluate a claims platform only by its feature roadmap. They're also buying a long-term operating relationship, which makes financial direction relevant to implementation risk, support quality, and future product investment.

DXC reported fiscal 2025 revenue of $12.87 billion, down 5.8% year over year from $13.667 billion in fiscal 2024 and from $14.430 billion in fiscal 2023, according to DXC's fiscal 2025 results. Its two principal segments generated about $6.6 billion in Global Business Services and about $6.2 billion in Global Infrastructure Services during fiscal 2025, showing a substantial operating base but also a business managing pressure across its latest reported periods.

The buyer risk isn't bankruptcy, it's priority

The more immediate concern for an insurer may not be whether DXC can operate its services. Its security operations footprint indicates industrialized managed-service delivery, with $500 million in fiscal 2023 security revenue, 3,500-plus cybersecurity professionals, 450-plus global customers, seven security operations centers, and presence in more than 40 countries, according to DXC's regional strategic business update. Those capabilities support confidence in large-scale operations, but they don't establish how much attention a particular insurance claims product will receive.

The fiscal 2026 figures and fiscal 2027 first-quarter materials add pressure to the investment question. DXC reported adjusted EBIT margin at 5.0% versus 6.8% in the prior period, as described in its fiscal 2026 results.

Claims leaders should ask for product-level release governance, named insurance leadership, support commitments, exit assistance, data portability, and a clear division between licensed functionality and billable services. The issue is not whether DXC has capability. It's whether the buyer can preserve strategic flexibility if the vendor's broader business remains under pressure. Independent reviews of specialized claims AI should be approached carefully, including claims AI review criteria, because feature enthusiasm shouldn't replace operational and financial diligence.

Integration Architecture for AI Claims Automation

A layered architecture works only when each system has a clear responsibility. The safest design usually keeps DXC or another enterprise platform authoritative for policy, claim identity, financial records, and regulatory data, while a specialized automation layer handles tasks that benefit from focused AI capabilities.

Establish system boundaries first

Start by documenting ownership. Define which platform owns the claim number, policy version, reserve, payment status, authority decision, correspondence record, and audit event. Without that map, teams create duplicate records and later spend effort reconciling conflicting versions.

Use secure APIs for synchronous exchanges where a handler needs immediate context. Use event-driven messaging for triggers such as a new FNOL, an uploaded document, a changed authority status, or an inactivity threshold. The integration layer should preserve correlation identifiers so every automated action can be traced back to the source claim and the relevant user or service.

A practical design has three layers:

1. DXC enterprise infrastructure: Stores authoritative records and supports existing claims, policy, financial, and reporting applications.

2. Integration bus and APIs: Orchestrates data exchange, authentication, retries, validation, and event delivery.

3. Specialized AI automation: Extracts information, classifies work, recommends actions, and sends approved updates back through controlled interfaces.

Build governance into every workflow

AI output shouldn't write directly to a financial or claims record without validation appropriate to the action. Low-risk extraction may proceed automatically when confidence and data-quality rules are satisfied. A coverage interpretation, authority decision, or settlement recommendation should create a review task when evidence is incomplete or the result falls outside configured boundaries.

Maintain an audit record containing source documents, extracted fields, decision rationale, model or rule version, human overrides, timestamps, and downstream updates. Define a fallback path for unavailable services, uncertain predictions, and rejected messages. Operational monitoring should measure queue age, exception volume, failed synchronizations, and manual override patterns rather than focusing only on model accuracy.

This approach follows the logic of microservices architecture patterns: isolate responsibilities, keep interfaces explicit, and allow one component to evolve without destabilizing the entire estate. The integration contract matters more than the AI branding. If a specialized service can be replaced without rewriting the policy and claims core, the insurer has preserved negotiating power and reduced concentration risk.

Building a Layered Claims Technology Stack

A resilient claims stack doesn't force one vendor to perform every function. DXC is better positioned as an enterprise foundation where insurers need legacy integration, infrastructure management, data controls, and broad operational support. Specialized tools should address workflow bottlenecks that require rapid refinement, including document interpretation, intake triage, delegated authority checks, and dormant-claim follow-up.

Match the layer to the problem

At the foundation, the enterprise platform should remain responsible for durable records, identity, security, financial integration, and reporting. The middle layer should coordinate claims workflows, business rules, queues, and user interactions. The top layer should automate focused tasks where unstructured information and repetitive decisions consume handler time.

That separation improves the quality of a business case. Instead of funding a wholesale replacement, a claims leader can identify a specific queue, establish baseline measures, and evaluate whether automation changes the work. Independent claims automation research projects processing automation rising from 15% in 2020 to 75% in 2023 and 90% by 2030, while projected processing time falls from 72 hours to 5 hours in 2023 and 1 hour by 2030, according to research on insurance claims automation. Those are projections from the cited research, not a guarantee for any DXC implementation.

The strongest use cases are usually bounded and observable:

• Document intake: Extract structured fields and route incomplete submissions.

• FNOL triage: Capture missing information and direct claims to the correct queue.

• Delegated authority: Check submissions against configured thresholds and escalate exceptions.

• Lifecycle monitoring: Identify stalled files and propose the next operational action.

Claims teams also need a practical way to streamline cases with a system when multiple people, documents, and deadlines surround each file. The technology choice should preserve handler control, expose every automated action, and avoid forcing staff into a separate portal for routine work.

A layered model also limits vendor concentration. DXC can continue supporting the core environment while a focused automation provider competes on workflow quality, implementation speed, and claims-specific governance. That isn't an argument against DXC. It's an argument for assigning each platform the work it can perform most credibly.

Real-World Implementation Scenarios

Consider a mid-sized Lloyd's managing agency with DXC-hosted policy and claims infrastructure. The agency doesn't begin by replacing its claims workbench. It selects a defined flow, such as delegated property claims arriving through broker email and requiring authority validation before handler assignment.

A new notification enters through the existing channel. An integration service creates or matches the claim record in the DXC environment, then sends the relevant message, policy context, and attachments to a specialized AI triage service. The service extracts claim details, identifies missing information, checks the submission against configured authority thresholds, and returns a structured recommendation with the supporting evidence.

The handler remains accountable

An event trigger places straightforward submissions into the appropriate work queue. A complex claim, an incomplete document set, or a result outside the authority boundary creates an escalation task instead. The handler sees the recommendation and source evidence in the established claims workbench, reviews the decision, and approves, changes, or rejects the suggested action.

Approved updates synchronize back to the authoritative claims record through the integration layer. Documents, correspondence, decisions, and overrides retain a traceable relationship to the claim. A scheduled reconciliation process checks for failed messages and mismatched statuses, while operational dashboards expose exceptions rather than allowing them to disappear between systems.

The agency's governance committee should approve the data map, review access permissions, define human-approval thresholds, and test fallback procedures before expanding the flow. It should also monitor whether automation changes queue composition, handler workload, and evidence quality. A board-level business case can then focus on measurable operational outcomes, such as shorter processing intervals, greater handler capacity, and fewer rekeying errors, without claiming improvements that the implementation hasn't yet demonstrated.

This scenario shows why the safest question isn't whether DXC or an AI vendor can own the entire claims lifecycle. The better question is which layer should own each decision, how the layers exchange evidence, and whether the agency can change one component without destabilizing the rest.

Nolana AI automates claims operations from FNOL through settlement with agentic workflows for intake, triage, document processing, lifecycle management, and delegated authority checks, while keeping human handlers in control and preserving an audit trail. If you're evaluating a specialized layer alongside DXC Technology or another enterprise claims environment, visit Nolana AI to assess how it can integrate with your existing systems.