Summary
- Forsikringens Datacenter A/S is a small Danish operating company whose F2100 software and services support critical insurance and pension workflows in Denmark, Norway, and Sweden; a recent regulatory report from Storebrand classifies its F2100 service as a critical or important outsourced function.
- FDC's shared software model spreads development and operating costs across clients, but this same common core concentrates specialised knowledge, release coordination, integrations, and recovery obligations. The risk is a concentration of workflows, not simply a concentration of data centres.
- A five-year extension with Kyndryl announced in 2025 adds another hardware layer: FDC's existing mainframe estate is being upgraded and moved to Kyndryl's Twins data centre in Belgium and its zCloud service. Public announcements describe the intended destination but do not disclose the full subcontracting map, recovery design, achieved service levels, or completed migration status.
- Exit is possible but consequential. Sygeforsikringen “danmark”, a former shareholder and client of FDC, chose Netcompany for a new platform in 2020 and indicated that its agreement with FDC ended at the end of 2024. This public timeline is a better indicator of switching cost than any claim that a modern interface makes a core system easy to replace.
- The best procurement test is therefore demonstrable reversibility: full data extraction, tested recovery, audit access through every subcontracting layer, priced transition assistance, continuity of scarce skills, and a rehearsed plan that keeps policyholders served while the institution changes its core system.
An address change, many hidden systems
Start with a transaction far too ordinary for a technology showcase. A policyholder moves house. The insurer may need to update the customer record, recalculate a premium, verify an address, update payment instructions, regenerate documents, keep an audit trail, and expose the result to an employee, an intermediary, and a self-service portal. For motor insurance, a vehicle record may also be relevant. For a pension, the seemingly simple equivalent might be a beneficiary change, a transfer, or the start of a benefit. Each action must land on the right contract at the right effective date without corrupting what came before.
FDC's own description of F2100 shows how far the resulting workflow extends. Its non-life and health system covers customers, events, policies, claims, payments, portals, communications, management information, and finance. Its life and pension system covers policyholder and policy creation, contributions and payouts, claims and pensions, policy endorsements, pension transfers, and call centre work. The company also lists connections to the Danish civil registration system, the vehicle register, the tax authority, the NETS payment infrastructure, and banks.
These are company published product scope descriptions, not an independent mapping of each customer deployment. They nevertheless make a point that is hard to dispute: a central insurance platform is not one application behind a single screen. It is where legal promises, money, identity data, and operational decisions meet.
That is why the name Forsikringens Datacenter can mislead an English reader. The subject is not primarily a landlord selling racks. Forsikringens Datacenter A/S — generally FDC — is a Danish insurance software and operations company. Its main product, F2100, is offered with development, consulting, maintenance, and operations services as software as a service. When Kyndryl announced a renewed partnership in September 2025, it said that FDC supportedmore than four million insurance policies or individuals in Denmark, Norway, and Sweden, mainly via F2100. That figure comes from a vendor announcement, so it must be treated as a current business claim rather than an audited operating metric. Its scale is nevertheless consistent with the client footprint that FDC publishes.
The address change also reveals the article's central distinction. Concentration begins and ends neither at the mainframe. It exists wherever a great many important transactions rely on the same release process, the same specialists, the same integration patterns, the same operating procedures, or the same upstream facility. A mirrored machine can reduce equipment failure risk while leaving a customer dependent on a single software estate. A second data hall can improve availability while both halls remain subject to one vendor's control plane.
A portable data export can be useless if the receiving system cannot reproduce years of product rules and effective-dated history.
The exact Danish company behind F2100
The precise operating identity matters because FDC's story can otherwise dissolve into its much larger owners and infrastructure partners. The company covered here is Forsikringens Datacenter A/S, Danish CVR number 10 31 76 30, at Lautrupvang 12 in Ballerup. Itsaudited 2024 annual reportstates that the current limited company was founded on 1 July 1986.FDC's corporate historystates that the operating organisation dates back to 1965, when Danish insurers created a shared computing centre. Both statements can be true: one describes institutional continuity, the other the current legal company.
The same annual report identifies Michael Engelbredt Knudsen as CEO and describes three business models. The first is the F2100 policy administration system for insurance and life-pensions. The second is large-scale software as a service delivered on a common IT platform. The third combines application management, customer-specific development, and operations. These descriptions are more useful than a broad industry label because they define the contractual surfaces a buyer must separate.
A software license, a hosted operation, a project change, and a managed application can have different pricing parameters, service commitments, intellectual property rights, and exit obligations even when a customer experiences them as one service.
The company is economically compact. In 2024 it reported DKK 135.2 million in gross profit, DKK 79.5 million in operating profit, DKK 61.5 million in net profit, DKK 91.8 million in assets, and an average of 50 full-time employees. Average headcount has fallen from 117 in 2020 to 87 in 2021, 63 in 2022, and 55 in 2023. The accounts expect a 20–30% lower result in 2025 due to lower activity. These are company-level financial facts, not measures of the total workforce that may support FDC through customers, contractors, affiliates, or Kyndryl.
They nevertheless frame a material question of key personnel and capacity: how much product, migration, and operations knowledge resides within those fifty FDC employees, and how much resides elsewhere under contract?
The 2024 accounts also proposed a dividend of DKK 61.4 million, close to the year's net profit, after DKK 69.9 million of ordinary dividends paid in 2024. That does not prove underinvestment; the company remained profitable and a dividend alone cannot reveal product spending adequacy. It does mean a prudent customer should ask how lifecycle investment is funded, which modernisation expenses belong to FDC, which to its parent or infrastructure provider, and how much is recovered through future fees.
A core system vendor's distributable cash and its obligation to maintain an aging product are related business questions, even when the financial statements do not answer them.
FDC's ownership changed in January 2018. The company announced that Total Specific Solutions, or TSS, hadacquired FDC from Gjensidige, Bupa Global, and Sygeforsikringen “danmark”. FDC says TSS then organised it into life and pension, non-life and health, and shared services. The ownership chain has evolved since the acquisition: FDC's 2024 accounts state that its cash flows are included in the consolidated accounts of Topicus.com Coöperatief U.A., while Topicus describes TSS as its vertical software group. Acurrent extract of company data from the Danish CVRidentifies TSS Denmark ApS as FDC's direct parent. The operating company remains FDC. Topicus, TSS, and Kyndryl provide relevant capital, governance, or service context; none should be substituted for the Danish entity that contracts and delivers F2100.
This boundary also corrects a tempting historical shortcut. FDC's 2018 press release stated that TSS was then part of Constellation Software. TSS was included in the2021 spin-off that created the publicly listed Topicus.com structure. Later corporate control documents still link Topicus to Constellation, but a current analysis should not simply repeat the 2018 ownership phrase as if nothing had changed. For an insurer, the practical questions are the current contracting entity, any guarantee, financial support, change-of-control terms, and which entities hold the relevant software rights — not a famous ultimate name.
F2100 is a policy factory, not a database
FDC traces the common F2100 base to 1988 and its expansion into life and pension to the late 1990s. Around 2000 it built unit-linked capability with Finanssektorens Pensionskasse. This history signals accumulated domain logic. Core insurance systems must represent products sold under different rules, versions, and tax regimes; retain effective-dated records over long periods; apply premiums, reserves, commissions, and benefits; and produce documents and reports that can be reconstructed later. They are policy state factories. The database is only one component.
FDC presents F2100 Life & Pension as an end-to-end system covering stakeholders, products, and processes. It says products can be configured via rates rather than programmed from scratch and that the platform handles guaranteed benefits, market-rate arrangements, and unit-linked products. In non-life and health, FDC says customer "superusers" can create products themselves, while event, customer, and policy modules feed automated claims and payments processes. Configuration is valuable because it reduces the amount of bespoke code needed for an ordinary product change.
It does not eliminate complexity; it moves complexity into parameters, rules, permissions, test cases, and governance.
The distinction matters when procurement. A buyer who only asks for the number of lines of custom code they will own may miss the broader dependency: the configuration model. Who understands the meaning and interaction of thousands of product parameters? Can an insurer export them in an intelligible, version-controlled form? Are rules documented independently of the running system? Can it reproduce a historical calculation after the people who configured it have left? Does the customer own test cases that establish equivalence in a replacement system?
A no-code product builder may reduce the marginal cost of a new rate while increasing the importance of FDC's domain model.
The same applies to integration. Public registers and payment rails make F2100 useful, but each connection creates a contract and a failure mode. A civil registration lookup may be unavailable. A vehicle register field may change. A bank file may be late or duplicated. A tax interface may require a new. The core system must distinguish an external outage from a failed transaction, retry without double payment, show staff what is pending, and keep enough evidence for reconciliation.
FDC's public solution pages establish that these connections exist at the product level; they do not publish their per-customer topology, queuing model, recovery objectives, or responsibility matrix.
Customer evidence confirms the product is integrated beyond the product literature. Storebrand Forsikring's2025 Solvency and Financial Condition Reportlists "FDC A/S" and the service "F2100 Kjernesystem Forsikring" in its table of critical and important outsourced functions. The jurisdiction indicated is Denmark. This is stronger evidence than a vendor logo: it is a regulated insurer's own current classification of the service.
An official Norwegian tax commentary provides another kind of confirmation. In a case concerning Gjensidige Pensjonsforsikring, the Norwegian Tax Administration describedremote data services purchased from the Danish Forsikringens Datacenter, including systems that managed customer pension accounts. The Supreme Court ruled that the services were subject to VAT on a reverse-charge basis and did not fall entirely within specified financial service exemptions. The ruling is not a technical design document. It is useful because it independently establishes a cross-border service in operation and shows that service classification can change total cost.
FDC's published client listincludes Gjensidige in Denmark, Norway, and Sweden; Storebrand, Frende, and SpareBank 1 in Norway; and other named users of individual capabilities. The exact combination of F2100 modules and service arrangements is not public for each name, and no reader should turn a website list into an assumption that all customers share identical infrastructure. The verified conclusion is narrower: FDC supports significant Nordic insurance workflows through a common product family, and at least one current insurer formally treats F2100 as a critical or important outsourced service.
The common platform is the economic trade-off
FDC's proposition starts with sharing. Its 2024 accounts describe the service as large-scale SaaS on a common IT platform. A common base can spread development, compliance, infrastructure, and specialist knowledge costs across customers who would otherwise bear them alone. For a mid-size insurer, this can be rational. Insurance regulation and national integrations create fixed work; a platform provider can implement the common part once and maintain it as a product.
Sharing can also mutualise scarce mainframe, insurance product, and accounting skills. A defect found for one customer can be fixed before it harms another, and common national changes can be maintained once. These are plausible advantages of the model, not findings about FDC's performance.
The trade-off has a downside. Common components create correlated changes. If multiple customers depend on the same code path or release mechanism, a defect can have a wider blast radius. A major regulatory deadline may cause every customer to claim the same limited specialists at the same time. A customer-specific change may have to wait behind platform priorities. A shared recovery plan may assume sufficient resources for one disruption but not a region-scale incident. Even when data and execution instances are separated, knowledge, tools, and decision rights may remain concentrated.
FDC's services pagemakes specific operational claims: online systems with 99.5% availability, systems and data mirrored across two centres, 24-hour operations, on-demand capacity, single point of entry, ITIL-based service management, and agreements governed by service levels. These claims are useful starting points but they are not a published service-level schedule or an assurance report. A 99.5% availability figure permits roughly 43.8 hours of downtime in a non-leap year if measured continuously; the actual contractual meaning depends on exclusions, measurement windows, severity definitions, planned maintenance, individual service components, and remedies. It should be interpreted neither as a 43-hour downtime guarantee nor as evidence that actual availability is low.
"Two centres" is also incomplete without a failure domain map. Mirroring may mean synchronous or asynchronous replication. Centres may share power, network operators, administrative identities, orchestration, staff, or a mainframe sysplex. Recovery may be automatic, manually declared, or data-reconciliation dependent. A design resilient for read access may not provide the same recovery for payments, claims, or batch processing. FDC's public page does not answer these questions, and its later Kyndryl announcement introduces a Belgian facility not explained on the older services page.
Buyers need a dated architecture and an assurance package, not a composite assembled from marketing pages published at different points.
FDC also says it uses service-oriented architecture, web services, configurable components, and dynamic web interfaces. In 2018 it described FDigital, a modern experience and integration layer meant to sit above F2100 or other core systems and run in the customer's chosen private or public cloud. Such a layer can be a sensible "strangler" strategy: moving journeys and integrations to newer services while the policy record remains stable. But coexistence creates its own controls.
The institution must know which system is authoritative for each field, how events are reconciled, what happens when the layer succeeds and the core system fails, and whether the new layer reduces or merely masks dependency on the old.
The best question about concentration is therefore not "Are all customers on one database?" Public evidence does not establish that. It is: what resources are shared, and at which layers? Codebase, release train, identity system, operations team, infrastructure provider, facility, network, integration gateway, recovery tooling, and product specialists can each create a different concentration. An insurer should inventory them separately. FDC's common platform may be a healthy economy of scale, but its value cannot be separated from the controls that govern correlated change.
A Danish service migrates to a Belgian mainframe
In September 2025, Kyndryl announced a five-year extension of its relationship with FDC. The companies said that FDC's existing mainframe estate would be migrated and upgraded to Kyndryl's Twins data centre in Belgium and moved to Kyndryl zCloud. They presented the move as a way to improve security, flexibility, cloud integration, and future scalability while avoiding disruption to ongoing operations. FDC's CEO said it would combine mainframe workloads with cloud-native technologies.
The announcement is important evidence of direction, not proof of completion. It does not provide migration milestones, current production location, recovery pairing, data replication mode, achieved service levels, test results, named subcontractors, encryption key control, or the exact workloads included. "Without disruption" is a stated outcome in a vendor press release. Until FDC or a customer discloses completion and independent assurance, it should not be turned into a statement that the estate has been successfully moved.
It nevertheless changes the dependency picture. An insurer may contract with FDC in Denmark while significant processing happens on Kyndryl's infrastructure in Belgium. Storebrand's regulatory report gives Denmark as the jurisdiction of its arrangement with FDC; that field should not be interpreted as a statement of physical data location. Legal jurisdiction, service provider domicile, processing location, backup location, support access location, and dispute forum are different facts. DORA makes several of them explicit contractual subjects.
Kyndryl also separately announced in 2024 that Storebrand — the same group whose insurance entity classifies FDC's F2100 service as critical or important — was moving its own mainframe workloads to a shared IBM z16 environment at theTwins data centre in Belgium. Kyndryl said Storebrand would use consumption-based pricing and described the facility's environmental credentials. That does not prove that Storebrand's direct workloads and FDC's F2100 workloads occupy the same technical partition, recovery domain, or network path. It reveals a named-vendor and named-facility convergence that warrants examination. A customer should ask whether its apparently separate direct and indirect services have common operational dependencies.
The move also illustrates why "mainframe to cloud" is too coarse. Kyndryl zCloud is a managed mainframe service, not evidence that F2100 has been rewritten into stateless public cloud software. A modernised IBM Z environment can improve capacity management, automation, encryption, and integration while preserving the application logic that makes exit difficult. That can be a prudent outcome. A stable policy core does not become deficient simply because it runs on a mainframe, and a distributed rewrite does not become resilient simply because it uses newer infrastructure.
What changes is the distribution of control. FDC can access infrastructure scale and specialised operations without owning every physical asset. Its customers add a provider under their direct provider. Incident management, audit, access management, and recovery now depend on rights that must pass through the chain. If Kyndryl uses other hardware providers, the chain lengthens further. An insurer's right to audit FDC is limited public evidence if FDC cannot provide equivalent evidence about the infrastructure on which the critical function relies.
Location adds a sovereignty dimension but not a simplistic one. Belgium and Denmark are both European Union jurisdictions, and Norway participates in the European Economic Area. Keeping processing within this legal space may simplify certain data protection and financial regulation concerns compared to an unrestricted global service. It does not answer the question of where support staff can connect from, where logs and backups reside, what law governs an access request, or how data will be returned on exit. "Hosted in the EU" is a boundary condition, not a full sovereignty control.
For customers, the migration should be managed as a critical service change even if FDC does most of the technical work. Evidence should include before/after dependency mapping, cutover and rollback criteria, data reconciliation, peak load testing, recovery drills, incident routing between FDC and Kyndryl, and confirmation that the customer's exit artefacts remain usable after infrastructure changes. Otherwise, modernisation may improve the platform while making the supply chain harder to see.
Implementation is an insurance transformation
FDC describes a consulting process that begins with a bottom-up needs analysis and an agreed joint solution description. It says consultants work across the entire insurance value chain and regulatory reporting, while delivery uses agile methods and testing ranging from unit and system to integration, end-to-end, and user acceptance. This is process evidence from the vendor, not a measure of any particular project's success. It accurately signals that implementing a core system is organisational work, not a software install.
An insurer must first decide what to keep. Existing products may contain clauses no longer sold but still owed to customers. Data may encode exceptions handled by staff rather than written into a clear rule set. Documents may be the only evidence of a historical decision. Replacing the core system requires mapping products, cleaning and reconciling data, reproducing financial results, redesigning work queues, training staff, and coordinating external parties. The safest migration often runs old and new processes in parallel, which temporarily increases cost and complexity.
FDC's own customer casesshow this pattern, albeit through a company-friendly lens. It says its relationship with Storebrand began in 2007 and that a CaseWorker Portal was delivered in phases over several years above a mainframe interface. It describes a 2011 conversion for a large municipal and commercial portfolio from Gjensidige, including a municipal policy with 2,000 locations. It also describes work from 2019 to 2021 to support the Norwegian Egen Pensjonskonto regime, including integration with the pension accounts registry. These are not independent case evaluations, and they do not disclose budgets or defects. They illustrate how many business seams and external systems a core system change touches.
An older independent financial document provides a concrete cost point. SpareBank 1 Forsikring's2010 annual reportstated that its defined-contribution pension portfolio was to be converted to F2100 in autumn 2011 and recorded NOK 23 million in project costs in 2010. The figure is historical, covers a particular scope, and cannot be inflated into a current migration quote. It remains valuable because it demonstrates that adopting a shared core system creates significant project expenditure on the customer side before the system is fully used.
Implementation burden does not disappear after go-live. Product configuration must be governed. Interfaces change. National rules require updates. Users need role-aligned access. Reconciliations must be performed. Batch processing windows compete with online demand. A customer may depend on FDC for changes and its own staff for business acceptance, with a system integrator or specialist provider between them. When an incident crosses these boundaries, accountability assignment matters as much as diagnosis.
Staffing is therefore part of the architecture. FDC's declining average headcount makes it reasonable to ask for skills and succession evidence, but not to assume service deterioration. Some work may have been automated, moved within the group, outsourced, or reduced after customer departures. Procurement should identify named key functions rather than focus on the total: F2100 product architecture, national regulatory knowledge, mainframe operations, security, database administration, integration, recovery, customer configuration, and migration.
For each, the buyer needs coverage, location, employment or subcontract status, attrition data, documentation standards, and a contingency if a specialist is unavailable.
Testing deserves the same specificity. FDC says it supports a hybrid landscape of stable core systems, web services, APIs, and cloud components. An end-to-end test should therefore prove a business outcome across these layers, not simply return a successful response. A policy endorsement should produce the correct premium, accounting entries, document, payment instruction, downstream event, and historical record. A resilience test should inject partial failure: the register is slow, a message is delivered twice, the portal times out after the core system has committed, or overnight processing misses its window.
The customer needs evidence that operators can identify and reconcile ambiguous state.
Implementation quality is ultimately measured by operability. Can customer staff understand why a calculation happened? Can they see a queue building before policyholders notice? Can FDC deploy a national regulatory change without forcing every customer to make the same business choice? Can the insurer reject a release or run a compensating control? These capabilities determine whether a shared core system behaves like a product the insurer governs or a black box it rents.
The meters behind the SaaS invoice
FDC does not publish a price list. Its services page says SaaS is billed on the number of users. AnFDC 2012 annual reportdescribed customer agreements as largely time-and-materials contracts based on hours and operations resources, or as pre-built solutions and components. Both sources date from different periods and may refer to different offers. Together they show at least the types of meters a buyer should expect: subscriptions, users, infrastructure consumption, product components, and project labour.
User pricing can align cost with the insurer's operational footprint, but the definition is decisive. Is a user named, concurrent, active in a month, or simply provisioned? Are brokers, service partners, bots, API consumers, and temporary project accounts counted? Does self-service reduce licensed users while increasing transaction or infrastructure fees? Are test, training, and recovery environments included? A pricing schedule should tie each meter to verifiable source data and provide a dispute mechanism.
Change economics can dominate the recurring subscription. A common platform may include regulatory maintenance and ordinary upgrades, while customer-specific products, interfaces, and reports are billed separately. The contract should specify who decides whether a change belongs to the common core system, how shared development costs are allocated, whether a customer can refuse it, and whether funded enhancements become available to other customers. Otherwise, the buyer cannot distinguish the economic benefit of sharing from a subsidy for the product roadmap.
Infrastructure modernisation adds another variable. The Kyndryl announcement about Storebrand explicitly mentions consumption-based mainframe pricing, but FDC's announcement does not disclose how infrastructure costs are passed through. A customer should assume neither fixed nor consumption pricing. It should get baseline capacity, growth ranges, peak and batch treatment, non-production environment cost, disaster recovery capacity, indexation, and how efficiency gains are treated. A migration sold as more flexible may increase unit transparency without necessarily reducing total spend.
Taxation is part of the model. The Gjensidige case shows that a cross-border package of data services may be subject to VAT by reverse charge depending on its legal classification. Tax treatment varies by customer and period, so it is not an adjustment to FDC's list price. It is an example of why total cost must trace the actual service bundle and jurisdiction rather than the commercial label "insurance solution".
Finally, exit should be priced before entry. Data extraction, mapping assistance, parallel running, archive access, knowledge transfer, licence continuation, and vendor cooperation can all be expensive precisely when negotiating power has shifted. A low subscription paired with uncapped transition labour is not a low-cost service. Buyers need pricing schedules, assistance caps, delivery milestones, and continued service terms that survive notice and dispute.
Lock-in resides in meaning, not file formats
Software vendors often answer portability questions with export formats. A complete exit from F2100 would require far more. An insurer must transfer policyholders, products, versions, claims, beneficiaries, premiums, reserves, commissions, payments, documents, correspondence, consents, access history, workflow state, and reconciliation evidence. It must preserve the meaning of each field and the rules that transformed one state into another. It must also decide what to do with records whose quality was tolerated by the old system but rejected by the new.
The most difficult asset may be product history. A contemporary product can be reconstructed from a clear specification. A portfolio assembled through mergers, regulatory changes, and manual exceptions may be encoded partly in configuration, partly in program logic, and partly in operational practice. If FDC employees know why a particular sequence of effective dates works, that tacit knowledge is a dependency even when the customer legally owns its data. Reversibility requires documentation, executable tests, and people who can interpret both systems.
Integrations multiply the challenge. A replacement must connect to identity, vehicle, tax, payment, bank, document, actuarial, finance, and customer channel systems. Some interfaces can be redirected. Others are tied to F2100's data model or its batch processing cadence. During parallel running, the institution may need two-way synchronisation or a temporary master data layer. Every bridge built for the transition can become a new source of drift.
The customer's organisation also changes around the product. Staff learn F2100's terms and workarounds. Controls and reports assume its rhythm. Brokers and service providers integrate to its interfaces. Audit evidence is collected from its logs. A portal may mask the legacy user interface, but the underlying workflow remains. These organisational adaptations are real assets while the service runs and real switching costs when it does not.
FDC itself argued in a2018 press release about its FDigital layerthat few insurers wanted to replace their core system because replacement could cost two to three times as much and take two to three times as long as building a digital layer. That multiplier is a company assertion without published sample or methodology. The strategic response — modernising journeys above the core system — is credible, but it can defer rather than eliminate the exit problem. A layer may reduce immediate disruption while another generation of products and interfaces accumulates below.
Switching cost is not intrinsically abusive. Long-term insurance obligations make stability valuable, and a specialised provider deserves pay for its knowledge. The governance problem arises when the customer cannot measure the dependency or create credible alternatives. A long, healthy relationship can include strong exit rights, repeated data exports, and independent skills. A nominally short contract can still be locked in if no replacement can interpret the portfolio.
The most revealing measure is not contract length but the time needed for safe substitutability. How long would it take to obtain complete data, validate it, reproduce calculations, connect external systems, train staff, run in parallel, and terminate the old service? Which steps can be done before notice? Which require FDC cooperation? Which is the longest-lead skill? A customer that cannot answer these questions has not converted its legal right to terminate into an operational capacity to leave.
“danmark” proves exit is possible — and slow
Sygeforsikringen “danmark” provides a particularly concrete case. It was one of the shareholders that sold FDC to TSS in 2018. Its2024 Solvency and Financial Condition Reportstates that significant IT operation and development was outsourced to FDC, Adapt, and Netcompany, and that the agreement with FDC ended at the end of 2024. The same report states that Netcompany was chosen at the end of 2020 to modernise the technology platform.
These statements do not publish a detailed replacement architecture or say that every historical FDC function was transferred in a single cut. They support a narrow inference: a former owner and long-standing customer undertook a multi-year modernisation and reached the end of its agreement with FDC roughly four years after selecting the new platform provider. The elapsed period likely includes more than a technical migration, but it provides a better empirical boundary for planning than an unsubstantiated promise of fast core system swap.
Theorganisation's 2025 reportsstate that insured members were only very moderately affected by the transition to the new IT system. It also links later staff adjustments to efficiency gains from the new platform. These are the customer's own statements, not an independent programme audit. They indicate that a significant change can preserve customer service and deliver an operational overhaul, while reminding a buyer that benefits arrive through process and people change rather than vendor substitution alone.
Historical governance disclosures add texture. In its2016 solvency report, “danmark” stated that significant IT operation and development was outsourced to FDC. It described monthly incident monitoring, quarterly service level and contract reviews, and recovery testing. That evidence is dated and should not be treated as FDC's current control design. It shows the kind of customer-side management required years before DORA formalised much of the contemporary expectation.
The case undercuts two easy stories. First, FDC is not impossible to leave. A customer with governance, funding, and a replacement programme can end the agreement. Second, exit is not a procurement footnote. The public sequence from vendor selection in 2020 to contract end in 2024 spans multiple planning cycles, regulatory reports, and operating budgets. During that period, the customer had to continue serving members while old and new arrangements coexisted.
It also shows why a customer lost by a vendor is not automatically evidence of failure. “danmark” described a modernisation and subsequent efficiency gains; the public documents reviewed for this article do not attribute the decision to a failure, breach, or contractual deficiency by FDC. Customers replace core systems for reasons of strategy, architecture, economics, and control as well as poor performance. A fair assessment notes the exit without inventing its cause.
For FDC's current customers, the lesson is practical. The best time to build an exit inventory is when the relationship is stable. Run representative exports, keep configuration descriptions, maintain calculation test packs, identify national interface owners, and estimate parallel running capacity. Contractual transition assistance is most credible when it is exercised in small pieces before termination. An annual portability drill may feel inefficient until it is compared to four years of dependency discovery during a live replacement.
Security evidence has a long memory
FDC's services page emphasises security, monitoring, mirrored systems, continuous operations, and controlled service management. Itsprivacy policystates that it processes personal data on insurers' instructions, applies appropriate technical and organisational measures, binds staff to confidentiality, and requires external subcontractors to meet minimum security standards. These are necessary public commitments. They are not a current independent assurance opinion, certification scope, or full list of subcontractors.
The most consequential public regulatory evidence is historical and adverse. Following a 2015 IT inspection, the Danish Financial Supervisory Authority issued apublic statement dated 12 April 2016. It found limited public evidence documented IT risk and security management at the enterprise level. The orders covered security policy and risk, documented management expectations, risk controls, vendor and outsourcing compliance reporting, access rights oversight, and security logging and monitoring.
That finding should be neither minimised nor projected unchanged into 2026. It is a decade old. The public evidence dossier does not contain the regulator's detailed follow-up, a current finding that gaps persist, or an independent report showing how each order was closed. FDC's subsequent corporate history says it increased its focus on IT security and ITIL, but that is a company narrative. The defensible conclusion is that FDC has a documented regulatory oversight history that makes current evidence particularly important.
No specific, credible public report of a major FDC outage or data breach has been identified in the frozen evidence set. That is not evidence that none has occurred. Outsourced insurance incidents may be reported confidentially to customers and authorities, absorbed into a customer's own reporting, or described without naming the provider. Conversely, the absence of a public headline should not be turned into insinuation. The correct procurement response is to ask for the incident register under confidentiality, not to fabricate a public incident narrative.
Current assurance must match the service actually purchased. A certification held by one facility would not automatically cover F2100 development. A software development control report would not necessarily cover Kyndryl's infrastructure. A group policy would not prove FDC's local implementation. The buyer needs the scope, legal entity, locations, systems, exceptions, customer compensating controls, and period covered. The public sources reviewed here do not establish a current ISO 27001 certificate, SOC report, or ISAE opinion for the entire FDC service; such evidence may exist privately.
Access is a particularly important control in a layered service. FDC or infrastructure provider administrators may need powerful rights. The customer must know how privileged access is approved, time-limited, recorded, and reviewed; whether production support can originate from outside stated processing countries; how emergency access works; and who investigates anomalous activity. Encryption is incomplete without key governance: the customer must know who can cause a workload to be decrypted and what happens to keys during recovery and exit.
Operational incidents also extend beyond cyberattacks. Software defects, capacity errors, network failures, failed batches, corrupted data, expired certificates, human changes, and external register outages can all interrupt policy service. The firstaggregate DORA incident reportfrom the European supervisory authorities counted 3,383 major ICT-related incidents in the first reporting year, roughly one third cross-border. System failures and external events were the main drivers; only about ten per cent were classified as cyberattacks. These figures cover the European financial sector, not FDC. They reinforce why an assessment of FDC should not reduce resilience to penetration testing.
The useful security conversation therefore starts with evidence continuity. What changed after the 2015 inspection? What current controls can be independently tested? How do those controls extend to Kyndryl? What incidents and near-misses reveal the service's real weak points? How quickly can an insurer get logs and facts for its own regulatory deadlines? Historical findings make these questions sharper, while current answers must come from current evidence.
DORA turns an exit clause into an engineering requirement
The European Digital Operational Resilience Act (DORA) has applied since 17 January 2025. It does not turn every software vendor into a regulated insurer, nor does it shift responsibility from the insurer to FDC. The regulation states that financial entities remain fully responsible when they use ICT services. That principle matches Storebrand's own outsourcing report, which states that its board retains responsibility for outsourced functions.
DORA's importance lies in the precision of the questions it makes unavoidable.Article 29requires financial entities to assess concentration risk, including whether a provider is easily substitutable and whether multiple critical arrangements depend on the same or closely linked providers. For an FDC customer, this analysis should cover both the F2100 common layer and the Kyndryl layer. Storebrand's announcements make this concrete: direct and indirect arrangements may converge on the same named infrastructure provider and the same Belgian facility even when the contracts appear separate.
Article 28 requires exit strategies for ICT services supporting critical or important functions where provider termination, deterioration, or failure could disrupt the financial entity. The plans must be documented, tested, and periodically reviewed, and must allow transfer to another provider or an in-house solution without business disruption or detriment to customers. That is far more demanding than owning a termination clause. It requires architecture, data, people, capacity, and a sequence that works.
Article 30 specifies contractual content for critical or important functions. Agreements must clearly describe services and subcontracting; identify countries where services and data processing and storage occur; require notice of location changes; protect availability, authenticity, integrity, and confidentiality; provide data access and return or recovery; set measurable service levels; support incidents; provide audit and inspection rights; define termination; and require a transition period. Each element directly matches a public uncertainty in FDC's evidence.
The subcontracting provision is particularly relevant. A customer needs to know which parts FDC can pass on to Kyndryl or another party, under what conditions, and whether material changes can be rejected or trigger termination. Rights must be exercisable, not simply copied into a contract. If an insurer can inspect FDC but cannot obtain evidence about the facility, platform administrator, or hardware software dependency below, the formal right may fail at the layer where the incident occurred.
The Danish Financial Supervisory Authority states that a financial entity must notify it of aplanned ICT arrangement supporting a critical or important function. That obligation means a material change at FDC or Kyndryl may be part of the customer's regulatory process, not just vendor management. The regulator was also conducting a thematic review of IT risk management and board ownership in Danish insurance and pension companies. Public results were not found in the evidence available for this article, so no conclusion about the reviewed companies is drawn.
A meaningful exit test for F2100 would start with a defined slice rather than a paper exercise. Select representative policy types, including an old product with endorsements, an open claim, a payment exception, and documentary history. Export the data and configuration. Have a team outside FDC's normal operating path explain the records, calculate expected results, and load them into an independent environment or validated transformation tool. Reconcile accounts, money, dates, and documents. Measure elapsed time, manual interventions, and unresolved semantics.
Then test deletion and archiving obligations without destroying the production record.
Recovery testing needs equal realism. A customer must know whether it can operate when the online channel is available but batch processing is not, when FDC is reachable but Kyndryl is not, or when the Belgian environment is inaccessible for an extended period. Manual workarounds must specify volume limits, authorisation, and subsequent reconciliation. A plan that assumes all external registers and payment rails are healthy during a vendor outage is not a severe but plausible scenario.
Board reporting must make concentration visible in business terms. Instead of "green mainframe", report which policyholder services are at risk, maximum tolerable disruption, evidence of actual recovery, unresolved single dependencies, portability progress, and upcoming changes. Include the customer's own resource constraint: an insurer cannot leave a vendor if it lacks a team capable of receiving the service. DORA may force documentation, but only the institution can preserve the knowledge and budget that make the document true.
Alternatives are migration strategies, not feature grids
FDC is not competing only against another Nordic software package. A customer can retain F2100 and modernise its channels around it; move some products to a new core system; adopt a vendor suite; commission a managed platform; or build more capability in-house. Each choice shifts the dependency rather than abolishing it.
For non-life and property insurance, Guidewire marketsPolicyCenter, BillingCenter, and ClaimCenteras a cloud-delivered suite. For life and pension, the Nordic provider Lumera offerspolicy administration and migration services. Other international and regional providers occupy both markets. Their public feature claims do not establish that they can reproduce a particular F2100 portfolio, meet a Nordic customer's timetable, or provide a less concentrated supply chain. A buyer needs a migration proof, not a feature-count win.
An in-house option gives more direct control but creates its own staffing and lifecycle burdens. The original economic logic that produced FDC in 1965 — sharing scarce IT and domain skills — has not disappeared. Cloud platforms can make infrastructure easier to acquire, but they do not provide decades of product semantics, national interfaces, or insurance operations. A small insurer leaving a shared core system may trade vendor concentration for key-person concentration within its own organisation.
A layer strategy is often the least disruptive. New portals, APIs, and workflow services can improve customer experience while F2100 remains the policy record. That can also create a two-speed architecture in which every new journey depends on synchronisation with a core system. The buyer must assign authority by data entity, design for partial failure, and decide when the layer is a destination rather than a permanent bridge.
A phased product migration can reduce cutover risk. New business starts on the replacement while legacy policies run off or migrate later. This avoids converting the entire portfolio at once, but insurance liabilities can last decades. Operating two core systems for years duplicates integration, reporting, security, and skills. The running-off system still needs to be patched and recoverable even if attention moves elsewhere.
Competition should therefore be assessed on five outcomes: faithful product conversion, operability during coexistence, national integration coverage, evidence for regulatory controls, and credible exit from the new vendor. Price and functional fit remain important, but a cheaper replacement that requires opaque proprietary conversion or another untested shared dependency may only reset the lock-in counter.
The procurement tests that expose real control
FDC must be assessed through demonstrations and evidence related to the customer's own portfolio. The following tests are not assertions that FDC currently fails; they are the questions implied by the public record.
Establish the legal and service chain.Name Forsikringens Datacenter A/S as the operating counterparty, then identify the parent company, hardware subcontractors, software rights holders, data centre operators, and support locations. For each, state the service, countries, data access, audit trail, financial dependency, and replacement option. Reconcile the answer with the Kyndryl migration plan and update after every material change.
Map business services to technical components.Start with claims payment, policy issuance, customer access, pension transfer, regulatory reporting, and other customer-defined critical services. Trace each through F2100 modules, interfaces, batch work, data stores, networks, identities, and external parties. Mark shared components and common administrators. A platform diagram organised only around servers will miss the business failure.
Demand evidence of achieved service.Obtain at least several years of availability and incident data under stable definitions, including excluded maintenance and degraded service. Separate online, batch, integration, claims, and payments outcomes. Examine near-misses and capacity events alongside reportable incidents. Compare contractual targets with maximum tolerable disruption and with actual recovery drills.
Test a severe recovery scenario.Fail a material layer, not a harmless test component. Demonstrate recovery with realistic data volume, unavailable staff, and a compromised or inaccessible primary environment. Verify reconciliation after service returns. Record dependencies on Kyndryl, telecoms, encryption keys, external registers, and customer decisions. Repeat after the Belgian migration reaches each material milestone.
Prove data and semantics portability.Export a representative portfolio including configuration, documents, history, workflow state, access records, and reconciliation totals. Use documented schemas and transformation rules. Have it interpreted by independent people. Recalculate selected policies and claims outside production. Record fields that cannot be mapped and the contractual obligation to resolve them.
Expose the release queue.Show how common platform, national, security, and customer-specific changes are prioritised. Identify who supports regression testing and who can defer a release. Provide examples of simultaneous urgent demand between customers. The customer must understand whether sharing speeds up a required change or places it behind other institutions.
Verify privileged access and evidence scope.Trace an administrator from request to approval to session to monitoring to review. Include FDC and infrastructure provider staff. Demonstrate how the insurer gets logs during an incident and how fast facts can reach its regulator. Show how rights survive subcontracting and how emergency access is revoked.
Make staffing measurable.For each scarce role, disclose coverage, succession, documentation, subcontracting, and geographic availability. Test whether a different team can execute recovery and data extraction. Total headcount is less useful than the number of people who can safely modify an aging calculation or restore the policy database at 3 a.m.
Decompose price.Provide definitions and baselines for users, transactions, capacity, environments, storage, projects, and regulatory changes. Model growth, contraction, a major migration, and a parallel running year. State which of Kyndryl's cost changes can be passed through. Include tax treatment assumptions and the evidence used for invoice reconciliation.
Execute exit before notice.Agree continued service, licences, access, transition rates, cooperation, knowledge transfer, archiving responsibilities, deletion evidence, and dispute treatment. Exercise components annually. A customer does not need to migrate every year, but it must be able to demonstrate that the path is not fictional.
Link governance to the 2015 findings without assuming they persist.Ask for current controls and independent closure evidence covering enterprise risk, management expectations, vendor oversight, access rights, logging, and monitoring. The purpose is not to re-judge a decade-old inspection. It is to verify that the current layered service has evidence where the historical public record showed weaknesses.
These tests favour neither insourcing nor a rival vendor. Any replacement should face the same standard. Their purpose is to convert resilience from descriptive language into observable capability and to price dependencies before they become urgent.
What the public record cannot establish
The evidence is strong enough to establish FDC's legal identity, operating model, product breadth, current critical role for at least one insurer, the announced Kyndryl direction, one historical regulatory intervention, and one multi-year customer exit. It is not strong enough to score FDC's current security or operational performance.
Public sources do not provide FDC's full current client count, the exact per-customer module deployment, the tenant separation model, production topology, recovery time and point objectives, actual availability, incident history, latency, software composition, vulnerability register, assurance reports, current certifications, encryption key model, or full subcontractors list. They do not indicate which workloads have completed the Belgian migration or whether each customer's data follows the same route.
The accounts show a profitable operating company with declining headcount but not revenue by product, recurring revenue, customer concentration, research and development spend, Kyndryl commitments, or contract length per customer. The dividend data cannot determine whether lifecycle investment is sufficient. Current customers may have strong contractual protections and private assurance invisible publicly.
Vendor and customer case studies are selective. FDC's claims about configuration, availability, implementations, and scale describe its intended or marketed service. Kyndryl's claims describe a partnership and target architecture. Storebrand and “danmark” report through their own regulatory and corporate lenses. The 2015 regulatory statement is authoritative for that inspection, not a current assessment. Each source answers a different question; combining them does not create an audit.
Pricing remains particularly opaque. There is evidence of SaaS billing by users and older evidence for hours, operations resources, and components, but no current public rate or representative total cost model. Competitor pricing is also incomparable without conversion scope. Any procurement numerical conclusion beyond the disclosed historical bills and the company's accounts would be invention.
Finally, no public evidence proves that shared usage has caused a correlated incident at FDC. Concentration is an exposure that can be well or poorly controlled, not an incident allegation. The absence of a named event can also not prove the exposure is harmless. What matters is whether customers can obtain and test the private evidence needed to close the public gaps.
Watch the chain, then watch the exit
The first monitoring point is the Kyndryl migration. Customers should look for evidence of completed milestones, validated rollback, recovery drills, and updated processing locations — not just another intention announcement. Any delay can be informative, but so can a rushed success claim that omits operational proof. The destination architecture should make the service easier to observe and recover, not just scale.
The second is FDC's capacity and product investment. Declining average headcount and a falling profit forecast may reflect a changing customer base or a more efficient group model. Monitor whether key skills, release cadence, and client support remain solid; whether parent and partner resources are genuinely engaged; and whether dividends coexist with transparent lifecycle funding. None of these signals should be interpreted alone.
The third is customer movement. A renewal of an F2100 agreement, a module expansion, or a named migration would reveal how insurers value the shared platform. Another exit would reveal where substitution becomes practical. Useful details are timing, coexistence, service impact, cost, and what stayed on the old system — not the headline that a vendor was won or lost.
The fourth is regulatory evidence. DORA incident reporting, Danish supervisory work, and insurers' solvency reports will progressively expose how institutions classify dependencies and test exit. Storebrand's current designation of FDC as a critical or important outsourced function provides a clear baseline. Future reports may show whether service locations, subcontracting, or concentration descriptions become more precise.
The last monitoring point is the one most organisations defer: an exercised exit. FDC's history demonstrates the economic power of sharing a core system. “danmark” demonstrates that departure can be done without evident member disruption, but on a timeline measured in years. Kyndryl demonstrates that modernisation can add a capable infrastructure partner while lengthening the accountability chain. Together, they point to a conclusion less dramatic than a warning about old mainframes and more demanding in practice.
FDC's value and its risk come from the same fact: it concentrates a large amount of insurance meaning into a service that a relatively small group of specialists can operate for multiple institutions. Replacing the computer does not dissolve that meaning. Calling the computer a cloud does not transfer responsibility. The institution is resilient only when it can keep every promise during a failure, explain every dependency to its board and regulator, and move the promises elsewhere when the relationship ends.