The Question After the Demo: Getting Ready for AI in SimCorp
The SimCorp AI sessions at last month’s Americas summit gave a clear picture of where the platform is heading.
The sessions demonstrated a question being asked in plain English, and then answered from the book of record, with the reasoning steps and underlying query available for inspection. They showed corporate action elections being handled conversationally, staged and then sent to a colleague for approval before anything was written. They also showed portfolio data being enriched with market research from a partner system, bringing the two together to give portfolio managers something they could act on before the morning meeting.
But in the corridors and around the stands, the same question kept coming up. It was much simpler than anything shown on stage, but much harder to answer: what do we actually need to do to make this work?
We heard it from client after client over the course of two days. And it is not a question with an easy answer.
Why there was no short answer
It would be easy to read the lack of a short answer as evasion. We don’t think that’s fair.
The honest answer to "what do we need to do?" is that it depends, and it depends on the specifics of each firm’s environment. No vendor presenting to several hundred people can give a definitive answer, because it is different for every organization in the room. And giving the wrong answer would be worse than not giving one at all.
But there is a difference between a question with no single answer and one that has no answer at all. This question does have an answer. It just isn’t a set of instructions to follow on screen. It is a list of things to understand about your own environment, and working through them is the real project. Most of that work has little to do with AI itself.
What setting it up actually means
Four things decide whether any of this works in your environment. None can be fixed simply by switching something on.
Where your data actually is: The headline capability on show, asking questions of your whole book in plain language, works by generating queries against a governed data model. Which means the assistant can only answer about what is in that model. If your instruments, structures, or performance data have not been brought into the model, the assistant will not know about them. It will not tell you that, either. It will simply answer a narrower question than the one you asked, confidently.
How well your data is described: This is the part almost nobody is looking at. Natural-language querying depends on a semantic layer: what each table means, its grain, how it joins, and what your business calls things. If you extend the model with your own structures but do not describe them to the same standard, you get a system that answers well about the standard model but vaguely about the parts that make you “you”, which are usually the parts you most wanted to ask about.
Who is allowed to see what: Every answer is meant to respect your permissions. SimCorp says as much publicly: agents "can only act on data the user is authorized to access." That is the right design, and it makes your entitlements an AI control surface. A question posed in English can reach across domains your existing screens kept comfortably apart. Any ambiguity in your permission model stops being theoretical the moment someone can ask one question and have the system decide where to look.
What it costs to run: Capability like this is typically consumption-priced, not priced per seat. If your budgeting process has never had to model spend that varies with how curious your staff are, that is a new muscle, and it is better built before the first invoice arrives than after.
Where the line falls now
Step back from the setup question and something larger becomes clear. For years, the interesting argument in our industry was whether to build on top of the platform at all. That argument is over, and not because one side won. The platform is bringing the agent layer inside it. SimCorp announced Agent Launchpad publicly in April as an ecosystem of agents from itself and curated partners. The release is explicit that it "will allow clients to build their own agents, with controlled access to data from SimCorp One and approved third-party providers."
So the question is no longer whether you build above the book of record. It is where you draw the line between what the system of record does and what gets built above it. That is now a decision you have to make deliberately, because the tools to cross it are being handed to you.
Our view is that the line has not actually moved. The system of record still owns the auditable truth: accounting, IBOR, and performance. That does not change just because the interface has become conversational. What has changed is that the last mile above the system of record is now economically viable to build, either by you or by the vendor. That last mile covers the exception handling, explanation, commentary, and judgment work that has always lived in spreadsheets and in people’s heads.
SimCorp says something similar itself. In its article “Agents that compound need common ground”, it puts it this way: "Best practice lives at the platform level; differentiation happens at the final mile, where each firm’s risk appetite, client commitments, and operating model are distinct."
We agree, and we would add the question that sentence leaves open: where does your final mile begin? That is not a question a platform can answer for you, and it is worth spending a morning on before anyone builds anything.
Any layer above the book of record reads from it and proposes. It does not become a second book. Everything else is detail.
The failure mode nobody demos
Here is what we think goes wrong for the firms that get this wrong, and it will not look like a disaster while it is happening.
It starts sensibly. A team builds something small above the book of record to answer a question the standard model does not cover. It works, so it grows. A second data source is added because that was easier than getting it into the warehouse. A calculation is reimplemented in the layer because it is quicker to change there than in the system of record. Within a couple of years, there are two places that can tell you a number. They do not always agree, and the one everybody actually uses is the one that was never designed to be the record.
Then the person who built the layer leaves.
Nothing in that story is stupid. Every individual step was reasonable and had a good reason at the time. That is exactly why it happens, and why the discipline has to be established at the start, when it costs nothing, rather than in year three, when it means a reconciliation project and an awkward conversation with your auditor.
The new tooling makes this easier to do, not harder. A builder such as Agent Launchpad, which will let your own teams create agents against the book of record, is a genuinely good thing, and it is also an efficient way to create a second source of truth by accident. The discipline and the tooling point in the same direction. It is the sequencing that people get wrong.
Three questions before anyone turns anything on
If you came home from a demo with the setup question unanswered, these are the three we would start with. None requires a conversation with the vendor, and all three are worth answering whatever you eventually decide.
What can our data model actually answer today? Not what the platform can do, but what yours holds. Take five questions your team genuinely asks each week and trace whether the data behind them is in the model and described well enough for someone who has never seen your configuration to find it.
Where is our line? Write down, on one page, what you will never let a layer above the book of record do. Circulate it before anyone builds anything. The page is short; the argument it starts is the valuable part.
Who runs this in three years? Not who builds the agents or anything above them, but who maintains it, who owns the cost, and what happens when they leave.
The firms that get value from the agents will not be the ones that moved first. They will be the ones whose data foundation was in a fit state when the capability arrived. That is unglamorous work, the sort nobody will ever demo on a stage, and it is the entire game.
We are working through the practical side of the setup question now, across versions and deployment models, and will write up what we find. If you’re wrestling with the same thing, we would genuinely like to compare notes. Click here to get in touch with our team today.
