The insurance industry has digitized sales, underwriting and customer interaction, but the flow of money itself is still through outdated channels. With Finsurtech.ai, Mirela Dimofte and Andrew Sims want to change the Redesign the way in which premiums and claims are paid, settled, reconciled and embedded in ecosystems.
For decades, insurers have been investing heavily in policy management systems, CRM platforms and digital sales channels. However, the underlying financial infrastructure – the way in which premiums are collected and claims are paid – remains largely fragmented, manual and bank-centric. This gap is increasingly limiting automation, customer experience and real-time insurance models.
Finsurtech.ai positions itself as a payment infrastructure developed specifically for insurance companies. Rather than adapting generic fintech tools, the company focuses on the specific operational complexities of the industry: multi-party settlements, brokers, MGAs, cross-border payment flows and claims payouts.
We spoke to founders Mirela Dimofte and Andrew Sims about why insurance companies need their own payment architecture and what happens when money moves as quickly as insurance decisions are made.
The insurance industry has digitized many front-office processes. Why are payments still one of the least modernized areas?
Mirela Dimofte (MD): In the last ten years, insurers have started to successfully digitize sales, underwriting and customer interaction. However, the underlying cash flows have often been left on old rails. Payment processing has historically been viewed as a technical back-office function rather than part of the core insurance architecture. As a result, claims and premium payments still run through fragmented bank transfers, pre-funded accounts and manual reconciliations, often spread across TPAs, MGAs and various internal systems.
Because these mechanisms “worked well enough”, investment tended to focus on pricing, products and client portals rather than how capital actually moves when a claim is settled or a broker is paid. Given today’s scale and regulatory expectations, this disconnect between insurance logic and payment processing leads to capital leakage and operational friction. Finsurtech.ai was founded to close this gap by treating payment architecture as a first-class component of the insurance operating model.
What no longer works within an insurance company if the payment infrastructure is not designed for the insurance logic?
Andrew Sims (AS) If the payment infrastructure is not designed for insurance, it mirrors the workflows of banks or payment service providers rather than the logic of claims and policies. This leads to a structural mismatch between what has been approved in the claims system and the execution of the payment itself. Data is scattered across claims platforms, banking portals, provider systems and spreadsheets, so no one has a real-time view of the entire financial lifecycle of a claim.
Operationally, this manifests itself in manual approvals, batch files and repeated checks just to make sure the right party gets the right amount under the right conditions. The finance department has to make up for this with pre-financing and buffers, the claims department struggles with losses and rework, and the reconciliation teams spend much of their time reconciling transactions that could have been “inherently correct”. In short, execution discipline lags behind claims processing intentions, and handling exceptions usually becomes an operational expense in its own right.
You position Finsurtech.ai as an infrastructure and not as a payment service. What is the difference in terms of architecture?
AS: A payment service usually focuses on processing individual transactions: Transferring money from A to B, by card, bank transfer or wallet. Infrastructure, by our definition, is an integrated control layer that connects claims decisions, partner logic and funding mechanisms end-to-end. Instead of providing just another channel, Finsurtech.ai embeds the settlement parameters directly into the payment instruction, and in some cases also into the payment instrument, and coordinates the processes across multiple banks, systems and partners.
In architectural terms, this means that we “sit under the products and processes and not next to them.
We translate an approved claims decision into executable rules: who may be paid, for what services, under what limits, and enforce these rules at the critical moment during the billing process. The same infrastructure can support virtual cards, instant payouts, multi-party settlements and other tracks. For insurers, this creates a uniform operational basis for premiums, claims, commissions and partner processes without forcing them to use a single provider’s proprietary payment product.
Where do you see the greatest inefficiencies today: in premium collection, claims payment, reconciliation or partner billing?
MD: All four areas have structural inefficiencies, but the greatest economic impact tends to occur at the interface between claims payment and reconciliation, particularly where delegated authority and complex ecosystems are involved. In claims payment, decisions become cash; any weakness in execution discipline, such as duplicate payments, out-of-scope benefits, delays, has a direct impact on the loss ratio and capital utilization.
The reconciliation then absorbs the downstream costs of this fragmentation. Teams manually reconcile bank statements to bordereaux, partner reports and internal general ledgers, often weeks or months after the event. Partner settlements compound the problem as funds are paid upfront to TPAs, MGAs or networks to compensate for limited control at execution. Our approach is to treat these areas as one cohesive process: Payments are governed at the time of settlement, and transaction-level data is automatically generated so that reconciliation and settlements with partners become by-products of execution rather than separate manual processes.
What is the structural difference between insurance payments and e-commerce or bank payments?
AS: In e-commerce, most transactions are one-off and bilateral: one merchant, one customer, one clear product and immediate settlement. In banking, payments are often account-to-account transfers with relatively simple business logic. Insurance payments, on the other hand, are multi-part, staggered over time and closely linked to provisions. A single claim can involve policyholders, repairers, medical providers, assistance partners, brokers and reinsurers, each with their own contracts and terms.
Furthermore, the final cost of a claim is not known in advance. Scope and pricing evolve as repairs are made or treatment plans change. Traditional payment systems were never designed to account for this dynamic insurance logic at the time of billing. Finsurtech.ai solves this problem by treating each payment as an instrument that includes the context of the claim, i.e. limits, authorized benefits and counterparties, so that execution can follow the technical intent of the policy and claims decision.
How does your platform handle multi-party payment flows? For example, with insurers, brokers, reinsurers and policyholders in a transaction chain?
AS: We start by modeling the economic intent of the transaction chain: who bears what share of the costs, who should be paid in what order and under what conditions? This logic is then embedded in our orchestration layer. Instead of pushing a large payment into the system and “sorting it later”, we create structured payment instructions for each party, each with their own parameters and controls.
For example, a motor claim could trigger a series of coordinated processes: a virtual card for the garage limited to authorized work, direct reimbursement to the policyholder and a settlement instruction to a reinsurer once certain thresholds are reached. All of this is based on the same claim and the same authorization context. The insurer maintains a consistent overview of the entire lifecycle: status, amounts, timing, while each stakeholder receives a simple, direct payment. Complexity is managed in the infrastructure, not in manual processes.
The payment of insurance benefits is an emotionally critical moment for customers. What does “real-time claims settlement” technically require behind the scenes?
MD: Real-time claims settlement is not just about speed, but also about having enough control and context to release funds confidently at the moment of decision. Technically, this requires integration between the claims system, the payment orchestration layer and the underlying rails. The claims platform should pass structured settlement parameters, such as approved amount, counterparties and terms, to the payment layer via APIs or in batches.
Our infrastructure then converts this data into earmarked instruments, such as virtual card numbers or instant payouts, which enforce these parameters at the decisive moment and authorization in the event of a VCN or approval at the time of account-to-account payments.
Real-time decisions also depend on immediate feedback: every authorization, rejection or partial approval sends structured data back to the insurer. This creates a feedback loop in which coverage decisions, customer communication and payment execution take place within seconds, but remain fully controlled and verifiable.
How do you integrate with legacy policy administration systems that were never designed for API-driven financial services?
AS: Many core systems in the DACH region and Central Europe are robust but monolithic. We are not asking our customers to replace them. Instead, we are introducing an integration layer that can receive events or files from the core system and import them into our platform. The integration patterns range from batch exports to APIs to event-based hooks, depending on the customer’s readiness and needs.
Once connected, the policy administration or claims system remains the “source of truth” for coverage and decisions, while Finsurtech.ai becomes the execution engine for payments and billing logic. Over time, insurers can move from batch-driven to near real-time integration without a radical migration. This approach respects existing investments while unlocking modern features such as virtual cards, programmable payouts and automated reconciliations.
Reconciliation is a massive cost factor in insurance finance. How much of it can realistically be automated?
MD: Our experience shows that a very large part of the reconciliation work is to compensate for poor data quality at the time of payment. When each transaction contains a unique claim reference, service category, provider ID and billing context, matching becomes a rules-based activity rather than manual detective work. In this environment, the majority of reconciliation lines can be automated, allowing staff to focus on genuine exceptions.
Finsurtech.ai achieves this by generating structured records at transaction level as part of the payment flow itself. The payment instrument is created from the claim, so the identifiers used by the finance department already match those used in claims processing and operations. Bank statements and partner reports are captured and automatically reconciled to this canonical general ledger. While this does not eliminate the need for financial oversight, it does turn reconciliation from a monthly fire drill into a controlled, exception-driven process.
Who is your main customer: the CIO, the CFO, the operations manager or the sales manager?
MD: The main sponsors are usually the CFO and the COO, often together with the head of the claims department. They feel the impact of payment efficiencies most directly in claims ratios, capital utilization and operating costs. At the same time, the CIO is an important partner as the solution affects core systems, integration patterns and security architecture.
There is often a cross-functional steering group: the finance department defines capital and liquidity targets, the claims department focuses on lead times and losses, operations on scalability and IT on architectural suitability. Managers from the sales and bancassurance departments are involved when the focus is on commission flows, embedded insurance or partner ecosystems. Finsurtech.ai is designed to serve all these stakeholders through a common infrastructure, rather than adding yet another siloed tool.
How do brokers and MGAs benefit directly from a modern payment infrastructure?
AS: Brokers and MGAs thrive on the quality and predictability of cash flows. When payments are late, opaque or inconsistent, it strains relationships and working capital on all sides. With a modern infrastructure, settlements can be scheduled and executed according to clear, programmable rules and by agreement, portfolio or transaction, reducing disputes and manual tracking.
As each payment is linked to a claim, policy or commission, partners gain more transparency about what has been paid and why. This reduces reconciliation efforts and allows brokers and MGAs to focus on growth and service rather than chasing settlements. In some models, they can also access VCN-based payouts for claims costs they manage, eliminating the need for large, pre-funded balances. This improves their liquidity while giving the insurer more granular control and visibility over partner-directed payments.
Do embedded insurance ecosystems (mobility, travel, platforms) require a fundamentally different financial architecture?
MD: Embedded ecosystems increase complexity in two ways: Firstly, they introduce non-insurance platforms such as mobility apps, travel portals or marketplaces as sales and sometimes claims contact points.
Secondly, they often work with high frequency and small ticket sizes, which is difficult for traditional batch-based billing models to handle efficiently. In this sense, they actually require more programmable financial functions.
However, the basic principles remain the same: clear rules on who should be paid, when and under what conditions, real-time transparency and strong governance at the point of payment. The core system architecture also remains unchanged. Finsurtech.ai is built as an extensible layer that connects to platform partners, processes microtransaction flows and still reconciles everything with the insurer’s claims and policy logic. This allows insurers to participate in embedded ecosystems without having to build customized payment logic for each partner and without needing separate systems for different distribution agreements.
Payments entail regulatory risks: protective measures, AML, cross-border compliance. How do you structure the platform so that it works in different jurisdictions?
AS: We design the architecture in such a way that regulatory responsibilities are clear and traceable. The platform can work with payment partners (banks, e-money institutions, card issuers and processors) in any jurisdiction, while Finsurtech.ai focuses on coordination, rule execution and data integrity. This allows us to leverage local compliance frameworks for AML, sanctions screening and safeguards without forcing insurers into a single banking relationship.
From a technical perspective, we ensure that each transaction contains the required metadata: Payer, Payee, Purpose, Claim Reference, Geographical Location, so that verification and reporting is accurate and auditable. Cross-border payment flows can be routed through appropriate corridors, with currency settlement and local requirements coded into the rule engine. For insurers operating in Switzerland, the EU and other regions, this means they can apply a standardized control system while taking into account local regulatory specifics.
Beyond regulatory tasks and partner models, we also address data sovereignty and data protection through technology design. Our architecture can be deployed on distributed database technologies that keep sensitive data within the required jurisdictions and still provide a single logical view for the insurer. Regional shards or tenants ensure that Swiss, EU or other local data never leaves approved locations, meeting national data residency requirements and regulatory expectations. Personal data is processed in full compliance with the GDPR and associated frameworks, including purpose limitation, minimization, strong encryption, access controls and verifiable cross-border transfers using appropriate safeguards.
Could payment data ultimately lead to insights for underwriting and vendor management?
MD: Yes, we believe that payment data is a largely untapped source of underwriting insight. Today, many models rely on static information and historical claims data, but not the detailed billing dynamics behind those claims. When each transaction is linked to specific services, providers, schedules and behaviors, patterns emerge that can influence both pricing and product design.
For example, providers or networks that regularly incur additional costs, have longer repair cycles or are frequently reopened can be identified and treated differently. Similarly, certain channels or product configurations may have different cost development profiles over time. Our job is to provide a clean, structured data set that underwriters and actuaries can use safely, without compromising privacy, to refine assumptions about frequency, severity and inflation of claims.
If insurers had fully programmable cash flows, what new insurance products would suddenly become possible?
MD: Fully programmable money allows insurers to move from a payment “after the fact” to funding well-defined outcomes in near real-time. This makes parametric and event-driven products far more practical at scale, as payouts can be automatically released to approved counterparties as soon as conditions are met. It also enables staged benefits, such as rehabilitation or repair packages, where funds are released incrementally as benefits are delivered.
In retail, one could imagine claims-linked wallets or virtual cards that allow for instant approval with tightly controlled usage, making claims processing more of a supportive purchase than a reimbursement process.
In the commercial sector, complex structures with multiple parties, such as construction projects or mobility platforms, could be financed by rule-based processes that respond to milestones, telemetry or IoT signals.
In all cases, the common thread is the same: the capital behaves exactly as the product designer intended, as the payment logic is coded directly into the process. These are the exciting conversations we look forward to having with our clients over time.
The questions were asked by Binci Heeb.
Read also: From understanding to implementation: How process intelligence is redefining claims handling
Search:
Sponsors:
