AI is moving insanely fast. Every week, a slew of new products appear, another foundational research lab raises billions of dollars, and Anthropic/OpenAI release a feature that nukes 100 startups out of existence. It’s tough out there and, well, we are out there.
In the financial services space, the competition is particularly fierce. There are now one or more platforms for practically every niche of the market (from equities, to fixed income, to private equity, to REITs, to banking and everything in between), in addition to cross-use-case platforms that have raised hundreds of millions in recent weeks. Many are bs, many make inflated claims they can’t back, many use aggressive sales tactics to plant a nice AI-coloured flag in the corporate customer’s slow-moving bureaucracy, hoping they will never pilot with a competitor. Of course, many are great products that are legitimately delivering exceptional value to those who use them.
Though I would love to talk about the VC-fuelled excesses that we’ve been observing in the industry, for now I want to discuss a more practical topic: why would someone build a platform with strict workflows when Claude with access to the appropriate source data MCPs can do (at first sight) pretty much the same thing as your platform… I guess I gave it away in the parenthesi’d comment already, but there are many factors to consider, and the tradeoffs are actually much less obvious than they seem at first.
Disclaimer: At Terrapin we sell fixed income reference, pricing, and document data (including via an MCP server), and we have also built a platform that leverages this data as a source for advanced municipal credit research, so although I have two products to push, I will try to keep this article as objective as possible leaning on what I have seen from over a year of experimentation at our company and from many conversations with other founders. The observations may not apply to other industries or even other niches within financial services - my hope is that this article may help a wider audience (as well as myself) in creating a mental framework for how to think about Claude, MCPs, data, and platforms. I hope it is particularly useful for those who, despite deep subject matter expertise, have little technical background and thus find themselves drowning in an ever changing landscape of AI buzzwords.
Disclaimer 2: I will at specific points include mention certain companies by name to make my points clearer. No mention should be taken as either an endorsement or criticism of that company or product.
Note: In this article I will use the term “Claude” as an umbrella term for desktop/web based products developed and operated by frontier AI labs, such as Claude Desktop, Claude Cowork, OpenAI Frontier, ChatGPT Workspace, etc. When referring to a specific Anthorpic or OpenAI model as accessed via the API I will explicitly use a model name like Sonnet 4.6.
The Building Blocks
When interacting with financial data there are typically two consumption modes: direct data feeds (via API/SFTP/S3/Snowflake) and workstations (via Bloomberg, FactSet, Eikon, CapIQ, etc). It is common for the large players, like Bloomberg, FactSet, Refinitive and S&P to perform both functions, selling direct access to their data via a feed, while providing workstation access with workflows that are optimized for interacting with said data. Naturally, not all data that is made available via the workstations is necessarily made available via the feeds, in order to maintain a high level of defensibility. Vendors will typically charge per seat fees for workstation access (which may or may not need add-ons to unlock the full extent of the data), and separately provide enterprise packages to pipe the data into your internal systems or integrate with your products. Pretty much every financial institution or capital markets fintech is buying one or both versions.
With the proliferation of AI, a new consumption mode appeared: the MCP. MCPs have become the de facto (and easiest to integrate) way for a product like Claude to interact with a data source or perform computer actions like reading and writing files. And indeed, it is quite impressive when you first use it. You add your connector, authenticate your service, type a query, and off it goes to fetch the data you need and produce the report you requested. Maybe it needs a few extra instructions here and there to know what tools to use and how to interpret the data, but overall it will do an excellent job.
MCPs have also become a common way for platform providers to integrate common-license data into their products. For example, Hebbia/Rogo/ModelML/Capsa all allow you to bring your own enterprise FactSet license to they can pull data into their platform on your behalf. For these platforms, this makes perfect sense: the user gets to enhance their product’s output with access to proprietary data, and the client foots the bill. Now for the user, the tradeoff is not so immediately clear. All of a sudden, it means that in order to fully realize the benefits and strengths of the platform, the client has to have a (presumably) expensive enterprise license, not to mention that the user’s license may or may not allow piping of data into third party platforms. Indeed, often these companies (like most capital market fintechs have historically done) choose to just buy the data in bulk and amortize it over their customers, so the customer doesn’t have to worry about bringing their own data license.
However, most firms will also by now have a Copilot/Claude/ChatGPT enterprise license, allowing them to plug those same data MCPs into that platform, such as within Claude Cowork, which is vastly cheaper on a per-seat basis than any specialized platform (or so it seems at first – I’ll get there). Add to that that most financial firms will also have access to some of the traditional workstations like FactSet Workstation, for which they are paying.
I think you can see where this is going: there starts to be an exponential number of service and data setup combinations, all with their pros and cons:
- “Modern” platforms can buy the data from the vendors and amortize the cost over their clients, or ask the client to bring their license to pipe via an MCP;
- “Legacy” platforms keep selling access to their workstations, but also selling traditional data feeds and also enabling integration of their MCP from the end-user into the user’s third party platform;
- Users want to access the same data that is available on the legacy platforms (which is deep and rich);
- Excel Add-ins from Anthropic and OpenAI now also function as an extra consumption platform that naturally integrates with MCPs but not with much else.
Capital markets firms are now piloting and combining an overwhelming amount of tools, data licenses, and platforms, in the hopes of eventually settling into the minimal set of most important ones. But make no mistake: right now, no one knows which way the pendulum will swing, so the best we can do is look at all the tradeoffs and hope to make an informed decision.
Will someone please do the math?
In most cases, buyers will optimize their purchases of AI products and data over 4 main axes: cost, scalability, accuracy, and interoperability.
Without wanting to turn into a thesaurus, simply put:
- Cost is, well, how much this whole setup is going to cost;
- Scalability is how the system scales to perform AI-assistant analysis or operations that far surpass the volume what a team can perform manually;
- Accuracy is how close to the truth or correct are the model outputs, per the user’s intention;
- Interoperability is how well the process integrates with the user’s existing workflows; e.g. working well with Excel is always a necessary feature since most finance professionals use Excel as their main operating system.
This is where the analysis gets interesting, because right now there is no setup that perfectly delivers all of the above. Since there are many combinations as I mentioned above, let’s look at the two types of systems that are in the title of this post and compare their pros and cons, drawing on our observations and experiments at Terrapin.
-
Claude Desktop/Cowork + data MCP
We’ve recently launched an MCP to allow users to access reference, pricing and source documents for US municipal bonds. I connect it to my Claude account, and I start typing away. I run a few queries, and after waiting a few minutes, voila, a fully-fledged reported complete with very pretty graphs and artifacts appears. I run another query, and I’m starting to think I found gold, given how good the output looks. There’s only one problem: I just consumed half of my 5-hour quota. Well, it’s not so bad, I’ll choose a weaker model, that should allow me to run more things. Ok, it seems that performance and accuracy has degraded using a weaker model. But ok, we’re getting the higher tier plan soon, which will allow me to run more queries with the top models.
Stepping out of first person now, Claude integrates natively or via MCPs with most workflows (it is almost an operating system by itself), allowing a user to upload reports into their Excel sheets, load it into OneDrive, and many many other useful integrations within broader agentic workflows. It is excellent, until you need to scale: at that stage, a user that needs to do for 1000 different instances what they just did for one instance (in our case, this could be credit research on a municipal entity) will be unable both from a scalability perspective, since Claude/ChatGPT desktop apps are not built to perform this type of task as scale, and the costs will become eyewatering. Claude is great, but their harness is built to go as many loops as it needs to gather all the information and return something decent to the user. It is relentless, and that gets reflected in your bill.
One extra factor worth mentioning: LLMs are simply not the right medium to perform monitoring or real-time operations. Many workflows in finance depend on notifications, alters and recurring execution of certain operations. If the bill is large when you run 1000 instances once, imagine running 1000 instances multiple times a day – it is simply not going to work.
Summing up: for a small to moderate amount of tasks, Claude + data MCP is a great choice, since it provides excellent task completion and integration at relatively low costs, and integrates with your existing data vendor’s MCP if they have one, reducing the barrier for use of enterprise data, which has historically required complex infrastructure setups and dedicated tech teams to integrate and maintain.
-
Specialist platform with integrated data
Now, looking at the shortcomings of the previous solution, it is somewhat clear what needs to be done well for a specialized platform, which may not have as much breadth of use-cases as a Claude platform, to justify its own existence: scalability and cost.
Drawing from our particular field, US municipal fixed income, the ability to perform customized peer analysis at scale is a holy grail. If a user wants to extract the latest DSCR or days cash on hand for 1000 entities to compare them, a purpose built infrastructure, model selection, retrieval model and delivery mechanism are the only way it will be achieved – this is simply not going to happen within Claude Desktop. This is the same pitch made by many of the platforms I’ve mentioned above (whether they have built-in data or integrate the vendor MCPs): you want to do something at a scale that would be manually impractical, within a predictable cost structure and budget. If the Gemini Pro we use under the hood decides to think 3 times longer than usual, the user won’t see a 3x bill increase, it will be priced in.
Now, in our particular case, we are both the data vendor and the platform provider (a la FactSet), meaning that we also achieve data cost efficiency that is impossible to beat – there is no extra cost, either our or from the user, for the use of the data in these workflows. I don’t know exactly how the math works in platforms where the users can bring their own enterprise licenses to be fed via MCPs, since neither the platforms nor the data deals are particularly transparent, but I expect that in some cases the data license cost may be higher than the platform cost in itself, which of course needs to be taken into consideration.
The ability for developers to tailor model selection and all sorts of smart retrieval, extraction and context engineering is, and will likely remain, a massive differentiator that a specialist platform can bring to the users. Anthropic and OpenAI are exceptional companies with some of the most talented people in the world, no doubt, but no company can be excellent at every single niche.
Summing up: when the use case requires the ability to perform tasks at scale, leveraging highly specialized knowledge, while having predictable costs, a platform with integrated data is likely a great choice, even if it lacks the rich ecosystem of integrations that a Claude Desktop or Cowork would cover.
Conclusion
As mentioned in the background section, there is a large amount of setups between platforms, MCPs, APIs, and all sorts of other hybrids, and I’m sure many more are yet to come. I would be particularly curious what the large full service providers like Bloomberg, FactSet or Refinitiv are thinking, since increasing access to their data via agents and MCPs reduces the need for access to their workstations, and improving their core platforms with better AI functionality reduces the need for access to their data through 3rd party platforms. We, for once, are betting on both: streamlined access to excellent data and documents via API for technical users that want to build their own in-house systems; via MCP for non-technical users that want to leverage the data into their existing AI platform and workflows; via our own platform to provide that extra level of scalability and specialization, under predictable costs, to obtain insights that would otherwise not be possible to produce.