SimCorp One: What It Actually Is, and Where the Hard Decisions Sit

I've spent the last 9 years implementing SimCorp Dimension at banks, pension funds and sovereign wealth funds , focusing on the foundational IBOR. One of the strongest criticism of the platform has been the complexity and as a result the cost of implementing it. SimCorp Dimension is almost infinitely customisable and without a clear plan on what is required, scope creep is almost always guaranteed.

In the past SimCorp has tried to counter these issue by packaging up Standards to be used with little customisation, but the reality has been that these still required a substantial amount of configuration and were not always suitable to the clent's individual requirements.

SimCorp One is the latest attempt to put some structure around an expanding platform, supplemented with a growing ecosystem of partners. Especially since the takeover by Deutsche Boerse, this has grown to include Axioma Risk, 360T FX and Clearstream amongst many others.

So, what exactly is SimCorp One?

SimCorp One is not a new product

This is the most important thing to establish, because it stops both clients and candidates chasing something that doesn't exist. SimCorp One is a consolidation and streamlining of offerings that were already in the market, brought under one commercial umbrella and one delivery model. The core technology wasn't torn up and rebuilt when the name appeared.

If you treat SimCorp One as a new system, you scope a system implementation. If you understand it as a repackaging with a standardisation and cloud agenda attached, you scope the thing that actually determines success: a series of decisions about how much of your own bespoke setup you are willing to give up.

What's in the offering, and what each part means in delivery

SimCorp Dimension remains the foundation, and still where the deepest expertise is needed — IBOR, instrument setup, accounting configuration, derivatives, corporate actions, batch and workflow design. Nothing about SimCorp One makes that knowledge less relevant. If anything, understanding why an existing Dimension setup looks the way it does is now more valuable, because that's the starting point for every standardisation decision.

SimCorp Data Management, formerly GAIN, is the web-based service for market and reference data: sourcing, validation, cleansing, exception handling, distribution into the core. In practice this is where a lot of programmes quietly succeed or fail. Every downstream promise — real-time views, analytics, and now AI agents — rests on this layer being right.

Axioma provides factor risk models, enterprise and portfolio risk analytics, and the optimiser used in portfolio construction. It came in via Deutsche Börse and is a genuinely separate discipline from core Dimension work.

Investment Analytics Platform (IAP) is the cloud-native performance offering. It replaces the native Performance Measurement and Performance Manager front ends with a web-based, API-first service, delivering attribution in seconds rather than overnight. It is still based on Performance and Benchmark Calculations within SimCorp Dimension, although theoretically it can be fed by another system as long as it adheres to the standard file format.

A migration to IAP therefore still depends on someone who understands the legacy calculation layer, the PBOR, and how the two stay in sync.

Investment Accounting covers both the in-platform capability and SimCorp's Investment Accounting Services, where parts of the operation are delivered as a service. The service route changes the work substantially: less configuration, more oversight, controls design and reconciliation.

New Order Manager and New Asset Manager are the modernised front-office modules, and SimCorp's clear direction of travel is that these become the standard for SimCorp One rather than an optional upgrade. Two practical points. First, moving to them is a workflow redesign opportunity, and treating it as a lift-and-shift wastes the investment. Second, front-office experience that stops at the classic cockpits is going to date quickly.

What is very important here is that most of these are still separate platforms, with the integration via one or more Communication Servers. Understanding this infrastructure and the flows of data will guide the resource requirements for your project.

SimCorp Standards is the part I find most interesting, and the part with real consequences.

The standards question is the real story

SimCorp has spent years fighting a reputation for being expensive and slow to implement. Current Gartner reviews still say it plainly: powerful product, budget and timeline badly underestimated.

The cause has always been customisation. Dimension is configurable rather than code-customisable — all clients run the same code base — but the configurability is so extensive that an empty install is effectively a blank sheet of paper. Two firms doing the same thing routinely end up with entirely different setups, and each of those setups becomes something to maintain, test and upgrade forever.

This has been a chicken-and-egg problem for as long as I've worked with the platform. Clients said they wanted to standardise; there was no comprehensive standard to adopt. SimCorp has tried standard packages before, with mixed take-up.

Under SimCorp One the attempt is more structural. Client environments are composed from standardised platform and application modules built from a shared code base, provisioned through automated pipelines rather than hand-assembled. What varies between clients is which modules they take, not how those modules are built, deployed or governed.

Whether this finally shifts the landscape is still an open question, and I'd be sceptical of anyone who tells you it's settled. But it does hand clients a real alternative to a long bespoke implementation phase for the first time — and with it, a decision they can't avoid.

This becomes very important already during the RFP stage. The question should not just be if functionality is available in the system, but whether it's covered by a standard and to what extent. Often these are answered as yes or no and while the answer might well be that Dimension can do certain things, it might require extensive and expensive configuration.

The two decisions clients are actually facing

If you're a new client, the sensible default inverts. Rather than designing a bespoke solution and standardising where convenient, you adopt the standard and customise only where it is a genuine business differentiator.

That sounds simple and isn't. It requires someone to establish, business area by business area, what the standard actually covers, where it falls short of your operating model, and what each exception will cost you — not just to build, but to carry through every future upgrade. Those trade-offs need to be articulated and agreed before the implementation project starts. Discovering them in build phase is how timelines slip.

If you're an existing client, the question is harder: would you benefit from replacing a sprawling, heavily customised installation with something more standardised and streamlined? This is fundamentally a risk assessment — replacing individual modules incrementally versus committing to a greenfield rebuild. Both routes are defensible. Both have failure modes. The wrong answer is expensive in a way that takes years to become visible.

Neither of these is a configuration problem. They're analysis and judgement problems, and that's where I think external help pays for itself.

Agentic AI: worth understanding, not worth panicking about

In April 2026 SimCorp announced Agent Launchpad at its Global Summit in Copenhagen — an ecosystem for deploying AI agents inside SimCorp One, drawn from SimCorp, curated partners, or built by the client. The target use cases are workflow automation and analysis across portfolio management, corporate actions, risk and operational support, with a shared governance framework and an audit trail for every agent interaction.

I am not an AI specialist and there is a lot of hype around the potential and the usefulness in the context of SimCorp has still to be proven. One use case is that it will make querying the data easier with conversational AI allowing users to query the database without requiring the need to understand DEX or SQL.

What I'd take from it now is that agents make the data layer and the integration layer more consequential, not less, and that governance and auditability are moving from nice-to-have to explicit requirement. Both are things you can start getting right today regardless of when you deploy an agent.

The cloud move isn't really optional

Clients still running on premise should plan for a move to SimCorp's SaaS offering. SimCorp has rebuilt client environments on a standardised cloud architecture, migrating data and integrations through controlled cutovers rather than lifting environments wholesale. On-premise is a legacy position now, not a long-term strategy.

The underestimated part is rarely the technology. It's the operational adjustment that comes with no longer controlling your own environment: release cadence, change windows, incident escalation, and the internal roles that quietly existed to manage infrastructure and now need repurposing. It also requires a clarity one who owns which tasks of running the platform. Not knowing who is responsible for user setup, batch or communication server failure resolution can have serious financial implications.

Where I help

I split my engagements into two phases, and I'm happy to be brought in for either.

Decision support, before a project is scoped

• Estate assessment. An inventory of what's actually configured, what's genuinely in use, what's dead weight, and which parts of the setup are a real business differentiator versus historical workarounds.

• Standards gap analysis. Mapping the current or intended operating model against the standard modules, and quantifying the delta rather than describing it.

• Trade-off articulation for decision-makers. Cost, risk and timeline of standard versus bespoke, per business area, in language a steering committee can act on.

• Incremental versus greenfield. A structured risk assessment of replacing modules one at a time against a full rebuild, including sequencing and what has to hold true for each option to work.

• Business case and target operating model, covering the people and process consequences of standardising — which are usually larger than the system consequences.

• Vendor conversation support. Knowing which questions to put to SimCorp, where the standard genuinely covers you, and where the answer is "with some configuration."

  
  

Implementation, once the direction is set

• Requirements and solution design on a standard-first principle, with every exception documented and justified so it survives the next upgrade.

• IAP migration, including parallel running, reconciling legacy and new figures, and the Performance Calculation and PBOR dependencies that scoping documents tend to omit.

• Data management: sourcing, validation rules, exception handling, and integration through the SimCorp Integration Model and APIs.

• On-premise to SaaS cutover: migration dry runs, interface rework, testing strategy, and the operating model changes that come with it.

• Post-go-live stabilisation and knowledge transfer.  Making sure you understand the details of running the platform rather than relying on ongoing support from either SimCorp or other consultants.

  
  

As an independent consultant who has worked for SimCorp for many years I can help you with a realistic assessment of the possibilities and potential pitfalls. Contact me now for an initial discussion.