The AI-First TPA: What a Ground-Up Architecture Would Actually Look Like

Every TPA in the level funded market is running technology that was built for a world that no longer exists: patched to handle requirements the original architects never anticipated, integrated with external systems through custom connections that break when either side updates, and maintained by people who understand either the technology or the benefits domain but rarely both. The result is not a software quality problem. It is a business knowledge problem expressed in code. Building something better requires understanding the domain first and the technology second. What follows describes the component architecture that would result if both were understood simultaneously. What AI can do inside this architecture today, and when the rest will be ready, is the subject of FWD.07.

Why the Current Architecture Fails

#

Three categories of failure. Each is structural. Patching any one leaves the other two intact.

The monolithic system problem. Most TPA technology stacks are one of two things: legacy systems built in the 1990s and 2000s that have been patched forward through two decades of regulatory change, benefit design evolution, and integration requirements the original designers could not have anticipated; or modern enterprise platforms (Salesforce, Microsoft Dynamics, ServiceNow) adopted because they were available and IT-approved, not because they were suited to the domain. Both categories produce the same result at the operational level.

Claims adjudication rules are embedded in code written by developers who did not fully understand the clinical or contractual logic they were implementing. The code works in the sense that it produces outputs. It does not work in the sense that the outputs are always operationally correct. A claim adjudicated against the wrong benefit schedule because the system does not cleanly handle mid-year plan design changes is technically a software defect. Operationally, it is a benefits knowledge defect that will not surface until the employer or the stop loss carrier catches the error, which may be months later.

Stop loss tracking in most TPA systems is manual or semi-automated because the integration between claims adjudication and stop loss accumulator reporting was never properly built. The adjudication system knows what was paid. The stop loss system needs to know what was paid, when, for whom, against which specific and aggregate attachment points, and whether the claim is eligible for reimbursement under the specific terms of the stop loss contract. Those are different data requirements, and the bridge between them is, in most TPA operations, a monthly spreadsheet extract.

Employer reporting is a post-hoc data export rather than a live analytics layer. The employer asks what is driving their cost increase this quarter and the TPA produces a report three weeks later by extracting claims data, formatting it, and sending it as a PDF. In a market where employers are choosing level funded specifically for data transparency (FWD.05), the reporting process is the weakest link in the transparency promise.

The enterprise tool problem. Salesforce is a CRM. Its native data model is built around accounts, contacts, opportunities, and cases. Benefits administration has a fundamentally different data model: members, dependents, coverage periods, claims, remittances, accumulators, stop loss buckets, network contracts, plan benefit schedules, and coordination of benefits relationships. Salesforce Health Cloud has extended the platform with a claims data model that includes Claim Headers, Claim Lines, Coverage Benefits, and Member Plans (Salesforce, “Health Cloud Data Model Gallery”). But these objects sit on top of the CRM architecture rather than replacing it. The result is a system that can display claims information but was not designed to adjudicate claims, track accumulators natively, or manage the complex temporal logic of coverage periods, COBRA continuations, and qualifying life events that benefits administration requires.

Integration platforms like SnapLogic, MuleSoft, and Boomi solve the data movement problem but not the data model problem. If the adjudication system and the eligibility system and the stop loss reporting system all have different representations of who a member is, when their coverage started, and what their plan covers, moving data between them faster does not resolve the inconsistency. It surfaces the inconsistency more quickly, which is marginally useful, but the reconciliation still happens in a human’s head or a custom script.

The knowledge problem. This is the central argument. The technology decisions in most TPAs are made by people who understand one of two things: technology, or benefits administration. Rarely both.

When a developer who does not understand benefits adjudication builds the claims processing logic, the system is technically functional and operationally wrong in ways that are invisible until an employer or a stop loss carrier catches the error. When a benefits administrator who does not understand data architecture specifies system requirements, the requirements are operationally correct and architecturally unimplementable in a way that can be maintained, extended, or integrated.

The architecture that follows is designed by someone who understands both. That is what makes it different from the systems currently in use, and it is why the components are defined by their domain function, not by their technical implementation.

The Component Architecture

#

The argument for components over monolith: each function in benefits administration has a different natural buyer, a different update cadence, and a different set of integration requirements. Building them as a single system optimizes for none of them. Building them as separable components with well-defined APIs between them allows each to be updated, replaced, or licensed independently.

Eleven components. For each: what it does, why it is separable, and why it matters. AI capabilities for each are covered in FWD.07.

Component 1: Eligibility and Enrollment Engine. Ingests member eligibility data from every format an employer actually sends (834 EDI transactions, Excel spreadsheets, CSV payroll exports, PDF census files, email attachments). Normalizes into a single canonical member record. Cross-checks against the employer’s census file. Produces ID cards, welcome materials, and HRA enrollment packets from verified data. Tracks life events, qualifying status changes, COBRA elections, and dependent aging-off in real time.

This is the most important and most neglected component in the stack. Every other system depends on it. Claims adjudicate against the eligibility record. Stop loss reporting is based on covered lives. Employer analytics are meaningless if the covered population is wrong. A claim paid for a member who was terminated two months ago is not an adjudication error. It is an eligibility error, and the cost is real. It is separable because it is entirely upstream of adjudication: a clean API that any claims system can query.

For the micro-employer segment (FWD.03), the administrative cost of eligibility management is a significant component of the per-group cost that makes the segment unprofitable. Automating this process is not optional for a TPA that wants to serve micro-employers at scale.

Component 2: Claims Intelligence Engine. Ingests raw claims data from any adjudication source. Applies clinical and contractual rules for anomaly detection. Flags potential fraud, waste, and abuse. Tracks accumulator progress toward stop loss attachment points in real time. Produces the data feed that drives employer reporting and stop loss communication. Separable because the logic is identical regardless of which TPA runs it: a well-built Claims Intelligence Engine can sit on top of any adjudication system through a standardized data feed. TPAs that cannot afford to rebuild their adjudication system can license the intelligence layer.

Component 3: Member Navigation Layer. Plain-language interface to benefits. Answers the questions members actually ask: is this covered, why was this denied, what will this cost, where can I get this done. Separable because the member relationship is valuable independent of which employer they work for or which TPA administers their plan. A navigation product that works across multiple TPAs is more useful than one locked to a single book.

Component 4: Employer Analytics Platform. Turns claims data into decision support: cost driver identification, utilization pattern analysis, stop loss trajectory forecasting, renewal scenario modeling, benchmarking against comparable employers. Separable because employers want this regardless of who administers their plan. Licensable as a white-label tool or sold directly to employers whose TPA does not provide adequate reporting.

Component 5: Broker Intelligence Portal. Portfolio view of level funded clients, renewal flags, proposal generation with market benchmarking, commission tracking. Separable because brokers work across multiple TPAs. A multi-TPA broker intelligence tool has a natural network effect and a clear SaaS revenue model.

Component 6: Stop Loss Integration API. Standardizes the data exchange between TPA and stop loss carrier. Automates monthly reporting. Tracks specific and aggregate accumulator progress in real time. Triggers notifications when claims approach attachment points. Manages claims submission and reimbursement.

Every TPA has this need. None has a standardized integration. All are doing it manually or through custom connections that break when either party changes their system. A standardized API between TPA and stop loss carrier is market-level infrastructure. For pooled micro-employer products with reinsurance at the pool level (FWD.03), this component is the mechanism by which aggregate reporting across hundreds of micro-groups becomes operationally tractable.

Component 7: SDOH Signal Layer. Enriches member and population data with zip-code-level social determinants of health signals: housing instability, food access, transportation availability, economic stress indicators. Routes high-risk members to community resources before those risks become claims. Feeds the employer analytics layer with population health context. Separable because SDOH data has buyers outside the TPA market (health systems, Medicaid managed care organizations, public health agencies).

Component 8: Compliance Monitoring System. Real-time tracking of employer compliance obligations: ERISA plan document currency, CAA transparency requirements, mental health parity documentation, HIPAA privacy compliance, DOL audit readiness. Generates the documentation an employer needs to demonstrate compliance. Separable because compliance requirements change independently of operational systems. Regulatory updates should not require system-wide rebuilds.

Component 9: Claims Repricing Engine. Sits between adjudication and payment. Applies the appropriate repricing logic: network contract rates for in-network claims, reference-based pricing calculations where RBP applies, Medicare-based pricing where that is the plan design, and plan-specific fee schedule overrides. Generates the Explanation of Payment to the provider and the EOB to the member with repriced amounts accurately reflected. Tracks the delta between billed and allowed amounts across the book.

Repricing errors are among the most expensive failure modes in TPA operations. A $40,000 hospital claim paid at billed charges when the plan design called for 140 percent of Medicare leaves $15,000 to $20,000 on the table. Multiplied across a book of business, repricing failures are a material financial problem and are nearly invisible in standard reporting because the reports show what was paid, not what should have been paid. Separable because repricing logic is contractual, distinct from adjudication logic, and varies by plan design.

Component 10: Coordination of Benefits and Subrogation Engine. COB identifies dual coverage, determines order of benefits, adjudicates primary claims, communicates with secondary payers, and recovers secondary payments. Subrogation identifies claims caused by third parties, files liens, and pursues recovery. Subrogation recovery rates of 2 to 4 percent of paid claims are typical, representing $100,000 to $200,000 on a $5 million plan year that most small employers leave on the table because their TPA is not pursuing it systematically. Both workflows are manual and underperforming in most TPA operations. Separable as a combined component because they share infrastructure: claim identification logic, member communication workflows, external party coordination, and recovery accounting.

Component 11: Rating, Quoting, Underwriting, and Benefit Design Engine. The four front-of-funnel workflows: rating (actuarial PMPM calculation), quoting (broker-facing proposal generation), underwriting (front-end screening and renewal assessment), and benefit design (plan architecture with cost, experience, and compliance tradeoffs). This is the right place to start building because every other component serves groups already rated, quoted, underwritten, and designed. The front of the funnel is where competitive position is won or lost. A TPA that can rate accurately, quote in hours instead of days, underwrite with its own data, and help employers design better plans is differentiated from the first interaction. For the micro-employer segment (FWD.03), quoting automation is the single largest driver of profitability because the per-group quoting cost is a dominant share of the administrative expense at small group sizes.

Sequencing: What to Build First

#

The full architecture is a multi-year investment. The question is which component, built first, generates enough commercial return to fund the next one. Three variables determine the answer, and only the reader can evaluate them for their own organization.

What the organization can actually build. Technology capability is not evenly distributed. A TPA with a strong technology team and benefits domain knowledge can build the Claims Intelligence Engine and the Employer Analytics Platform. The Member Navigation Layer requires LLM expertise that most TPA technology teams do not have. The Stop Loss Integration API requires carrier relationships that a new entrant cannot easily develop. The gap between what an organization can build and what it would need to hire or partner for determines which components are near-term options and which require a different go-to-market path.

What the market will wait for. Employer analytics and quoting automation are needed now. Brokers and employers are asking for them. The SDOH signal layer and fractional worker coordination are emerging needs. Building ahead of market readiness burns capital. Building behind market readiness cedes ground to faster movers. The timing question is component-specific: each has a different market urgency.

What the capital structure allows. Component 11 (rating, quoting, underwriting, benefit design) has the fastest payback because it directly reduces cost and increases competitive win rate on every new group. Component 1 (eligibility) has the highest impact on operational quality and member experience. Component 6 (stop loss API) has the broadest market applicability as infrastructure. The right starting point depends on whether the TPA’s binding constraint is cost, quality, or scale.

Why Now

#

Three capabilities became simultaneously available that were not available three years ago.

LLM capability crossed the threshold for member navigation and document generation. The Member Navigation Layer (Component 3) and the plan document generation within Component 11 are now buildable at commercial quality. They were not in 2021. The gap between what a member navigation product needed to do and what language models could reliably do has closed. FWD.07 assesses the specific readiness of each LLM application.

Price transparency data became available at scale. The CMS hospital price transparency rule (effective January 2021) and the transparency in coverage rule (effective July 2022) produced machine-readable price files that make employer benchmarking and provider cost comparison tractable. Most of this data is unused because nobody has built the layer that makes it operationally useful to benefits administrators and plan sponsors. Component 4 (Employer Analytics) and Component 9 (Claims Repricing) are the consumers of this data.

SDOH data reached commercial viability. Zip-code-level SDOH datasets from vendors like Socially Determined, Findhelp, and NowPow are now commercially available with the geographic granularity and update frequency that makes them operationally useful for benefits administration. Component 7 (SDOH Signal Layer) was conceptually attractive three years ago. It is commercially buildable now.

The window is not permanent. The large carriers have the capital to build this architecture. The insurtechs, led by Angle Health with $200 million in total funding and 26-fold revenue growth (FWD.05), are building it from scratch without legacy constraints. The HR platforms have the employer relationships and the technology infrastructure. The TPA’s advantage is domain knowledge, carrier relationships, and the operating experience that comes from being in the market. That advantage is real and time-limited. The competitive timeline is the subject of FWD.08.