Every tool in your stack can do almost everything. The real question is whether it should.
On a recent client call, we were deciding where a piece of decision logic should live. We stopped asking which tools could do it and focused instead on:
- Time-to-value platform selection
- How quickly it could get into a user’s hands
- How often it would change
- Who would own it 18 months from now
That is what made the answer clear.
The data team wanted it in the warehouse, and it absolutely could go there. It could also live in the data layer above it, on the platform, or in an integration tool. We found ourselves saying: you have a lot of tools, and all of them can do this. The real question is, should they?
That is the challenge.
Not long ago, technology selection was mostly about capability. Can this tool do what we need? If yes, buy it. If no, choose something else. The product sheet usually gave you the answer.
That has changed. Almost every platform in a modern financial services stack can now do almost everything. Your warehouse can build a decisioning model. So can your data cloud. So can your CRM platform. So can a large language model connected to the right data. But many organizations are still making decisions as if capability is the only question. In our experience, that is creating unnecessary cost, delay and complexity.
What a slow tech stack decision costs: $1 million versus $40,000
Let us start with a real example. We have removed the client’s name, but the situation is exactly as it happened.
A bank we work with has a well-built, well-governed Snowflake environment doing exactly what it should. It also has what almost every successful data platform develops: a large backlog. Every request, no matter the size, waits in the same shared data engineering queue. The problem is not that the system is failing. It is that too much work is waiting for the same team.
Customer segmentation was sitting in that queue. The goal was simple: put the right offer in front of the right customer instead of sending the same message to everyone. The request had been approved and prioritized, but there was no date. In a long backlog, a yes without a date starts to look a lot like a no. That is how value quietly disappears.
There were two credible options: build the segmentation in Snowflake, where the data already lived, or have Snowflake feed Data 360 and run the segmentation there.
Built in Snowflake | Snowflake feeds Data 360 | |
|---|---|---|
First version live | 3 months | 2 weeks |
Live again after the first change | 6 months | 4 weeks |
Who maintains it | Shared data engineering queue | Platform admin |
Why the second change matters more than the first build
The second row is what made the decision clear, and it is the row that rarely appears in a business case.
The first version of any segmentation model will need to change. You put it in the market, learn from it, and adjust. With Snowflake, that change goes back into the shared queue: prioritize, build, test, and release. That means another three months.
In Data 360, it is closer to another two weeks. The honest comparison is not three months versus two weeks. It is six months versus four weeks, because the slower path pays the queue twice.
That is roughly five months of difference.
Putting a dollar value on five months of delay
The next step is to put a value on those five months.
If you are not putting a relevant offer in front of a customer, someone else is. Using the bank’s own numbers for new account openings, the missed opportunity during that window was approximately $1 million. The annual Data 360 consumption for the workload was about $40,000.
$1 million versus $40,000. That is a straightforward decision. And it becomes even clearer when you consider the second change, the third change, and every change after that. The revenue window closes once. The cost of a slow change cycle comes back every time.
The business case was two lines: revenue lost while waiting and the cost of the faster option. No maturity model or three-year roadmap was required. These decisions often sit unresolved because the invoice is visible and the opportunity cost is not.
When the same framework sends work back to Snowflake
This is also why the framework matters more than the tool. Change the numbers and the answer can change. If Data 360 consumption were $1 million a year instead of $40,000, waiting three months could be the right decision. You pay once to move the data, but you pay consumption every month. Same framework, different inputs, different answer.
We saw the reverse case on the same call. A high-volume transaction workload belonged in Snowflake. The logic was stable, it rarely changed, and billions of records a month were involved. Data 360 was not the right home. But take a similar-looking data set – for example, each member’s balance once a month for six months, so a banker can see whether the relationship is growing or shrinking – and the answer can flip. Similar data, different use case, different layer.
We later walked through the math with a highly experienced bank data leader. His response was not immediate agreement or disagreement. It was, ‘I had not thought about some of those things, and I will now.’ That stayed with us. Even the people who know the data best are not always asked to price the delay. If the number does not exist, it is easy to ignore. So how do you make the decision intentionally, instead of relying on instinct? That is the framework we use at Fortimize.
The 4 layers of a modern financial services tech stack
It helps to be clear about what each layer is there to do. Most bad routing decisions are really layer confusion, not tool confusion.
1. At the base are the core systems: core banking, loan origination, property management and other systems of record for the transaction.
2. Above that is the data and movement layer: the warehouse, ETL, data quality and integration tools. This is where volume, history and movement belong.
3. Next is the experience layer: the CRM and the tools configured around it. This is where bankers and other users actually do the work.
4. Now there is a fourth layer: intelligence. This is where we see the most confusion. A feature that summarizes information already on a record and displays it in the user’s screen is not a separate intelligence layer. It is part of the experience layer. It may be useful, already paid for and worth enabling, but we should be clear about what it is.
The intelligence layer is where you ask questions across systems, especially when the question or context changes each time.
What each tool should own, from Snowflake to Salesforce Data 360
Here is how we would divide the work, along with the most common ways we see each tool misused.
Layer | Tool | Should own | Goes wrong when | Change cycle |
|---|---|---|---|---|
Data | Enterprise warehouse (Snowflake, Databricks, in house) | High volume transformation, historical depth, feature stores, cross system reporting | It becomes the default home for logic that changes monthly | Weeks to months, shared backlog |
Data | ETL and data quality (Informatica, Fivetran) | Scheduled batch movement, plus rules based cleanliness: householding, dedupe, address and identity matching | It is asked to interpret rather than apply rules | Days to weeks |
Data | Enterprise integration (MuleSoft) | Real time API orchestration, complex many to many mediation | Used for simple point to point batch, where cost outruns need | Weeks |
Data to experience | Data cloud layer (Salesforce Data 360) | Fast assembly of customer context, decisioning, activation into the platform | Asked to carry very high volume processing or deep historical analysis | One sprint |
Experience | Platform configuration | Logic that lives in the user’s screen and process: workflow, approval, layout | Asked to do heavy transformation or large scale batch | One sprint |
Experience | Out of the box platform AI features | Summarising what is already on the record, no build required | Treated as an intelligence layer rather than an experience one | Configuration only, days |
Intelligence | Model and connector layer | Questions that span systems, contextual analysis, work where the question changes every time | Used for high volume repetitive jobs where the answer is the same daily | Hours to days |
Two areas are worth calling out.
Informatica and rules-based data quality
Informatica is often bought for integration and then underused. One of its strongest use cases is rules-based data quality. Householding is a good example: recognizing that two people at the same address and within a reasonable age range may be a household, without waiting for them to open a joint account. That has less to do with CRM and more to do with clean data and a better customer experience. Many institutions already own this capability and are not using it.
What the model and connector layer is for
The model and connector layer is misunderstood in both directions. It is not a replacement for a warehouse. It is very powerful when the question changes each time, and very expensive when the answer is the same every morning.
Three questions behind every tech stack decision
Once capability is a given, we use three questions. They are simple, practical and can usually be answered in an afternoon.
1. How many days until it is in someone’s hands?
Not days to design approval or the first sprint. How many days until a banker, underwriter or leasing agent can use it in their job? That number is often two or three times longer than the estimate because the queue is left out. Ask for a real date, then ask what needs to be true for that date to hold.
2. How often will it change, and how long does one change take?
This is the question that gets skipped most often, and it drives many of these decisions. It is what turned the segmentation comparison from three months versus two weeks into six months versus four weeks.
Put the two numbers beside each other: how often you expect the function to change, and how long it takes to move a change from request to production. If the change cycle is longer than the time between changes, you have likely chosen the wrong tool.
This can send work in either direction. Commercial use cases are tuned constantly, so a long change cycle can make the capability outdated before it delivers value. High-volume, stable work belongs in the warehouse. Transaction history is a good example. Volume and processing needs make that decision clear.
3. Who owns it in eighteen months, and what do they need to know?
Name the person or role, not just the team. Then ask what skill is required to make a change, whether that skill exists internally, and whether every update will need a new statement of work. A strong solution that your team cannot maintain is still a dependency.
It is also worth looking at the shape of the maintenance. Some tools make the initial build harder but future changes easy. Others make the build easy and turn every change into a small project. The build happens once. The changes continue for years.
Does your data need to be perfect before you use AI?
We have all heard the same advice: get your data organized before you start using AI.
But what happens if you do not?
Technically, a capable model can work through a messy environment and still find what you need. It can be done. As our CEO, John, said when we were talking about this, it is not intractable – it is just not economic or efficient. You will spend more time and more consumption doing it the hard way.
That changes the conversation. ‘Get your data in order first’ is not always a hard prerequisite. It is a trade-off. You can pay more in consumption now or invest more time in organizing the data first. Both have a real cost, and both should be visible in the decision.
The institutions struggling most are not always the ones with the messiest data. They are often the ones that put every idea behind a large data program and are 18 months into a two-year roadmap with nothing in a user’s hands. The bank in the earlier example is the less severe version: the data platform is live and delivering value, but the backlog is still quietly delaying every new idea. The more severe version is a long list of capabilities on hold with no one able to say what the delay has cost.
We saw this on a project where the client’s warehouse team estimated six to nine months to ingest a credit report, build a complete view of what the customer held elsewhere, and generate product recommendations.
We built it, tested it and had it live across the branch network in 12 weeks.
Same outcome, same data, very different timeline.
Right tool, right time: write the decision matrix down
The most useful outcome from that client call was the realization that everyone was making these decisions by instinct, one project at a time. The data team was optimizing for one thing, we were optimizing for another, and the platform vendor had a third perspective. No one was necessarily wrong, but the decisions were still inconsistent.
The fix is simple: write the matrix down.
For every tool in your stack, define what it is best at, the use cases it should own, how long it takes to get something live, how long changes take after launch, and who maintains it. Keep it to one page and agree on it before there is a project under pressure.
Then, when a new idea comes in, you are not reopening the architecture debate. You are routing the work. Your internal teams and partners use the same criteria, no matter who is in the room.
The organizations furthest along have not consolidated everything into one tool. They use several tools intentionally, each for the work it does best, and they are clear about the boundaries. Consolidation can simplify governance, but it does not automatically create better architecture.
A clear matrix also gives you the credibility to say no. Fortimize has no interest in moving every workload onto the platform layer. A framework that sometimes sends work back to the warehouse is one people can trust when it recommends a different path.
The real question behind every tech stack decision
Your tools can probably all do it. That part is settled.
The questions that matter are: where should the work live, how quickly can it get into a user’s hands, how easy is it to change, who will own it, and what is the cost of waiting?
In most technology stacks, the slowest part is no longer the technology. It is the decision.
