DEV Community

Cover image for OpenAI’s ChatGPT for Financial Services
Shrestha Pandey
Shrestha Pandey

Posted on AI-assisted

OpenAI’s ChatGPT for Financial Services

OpenAI launched ChatGPT for Financial Services on September 10, 2026. I saw the headlines calling it "ChatGPT for banks" and my reaction to this industry-specific launche was like, is this an actual new model, or just a repackaged product with a new landing page and a press release full of logos.

So I spent a few hours looking through the launch details, the model documentation, and the coverage to figure out what's genuinely new here.

The model behind it

The model doing the work is GPT-6 Astra, OpenAI's current flagship. There's no finance-tuned variant hiding underneath this product. OpenAI actually built a layer around Astra: built-in financial data, firm-specific templates, and a governance setup that a compliance team can sign off on. The model is the same one you'd get calling the API directly.

You're not looking at some specialized reasoning engine trained on years of SEC filings. You're looking at a general-purpose frontier model wired into a very specific data and access-control stack.

A few things about Astra itself matter for understanding what this product can actually do:

It supports close to a million tokens of context and it's important when you're throwing a 10-K, three years of transcripts, and a set of comps into one session and asking it to reason across all of it.

The API also exposes a reasoning effort setting, with levels going from low up to max. If you're building your own pipeline on top of this rather than using the chat interface, that knob lets you decide how much thinking time (and cost) you want per call, which is genuinely useful when some requests are "summarize this memo" and others are "build me a full comp table with sourcing."

On the OfficeQA Pro benchmark, which OpenAI uses as a rough proxy for office and financial document work, Astra jumped about ten points over the previous model. And on agentic, terminal-style benchmarks, which feel closer to what "build me a model" actually requires under the hood, Astra beat both its predecessor and Anthropic's comparable model at the time, at a lower cost per task.

One thing I noticed while reading the model's system card, worth flagging even though it's not directly a finance concern: this is the first OpenAI model to cross into what they call the Critical tier of cybersecurity capability under their own internal framework. That tells we're dealing with a genuinely different capability class than what most teams have been building agents on top of over the last couple of years, and OpenAI is gating some of that access accordingly.

Why Wall Street shaped the product

Morgan Stanley and Evercore worked with OpenAI as design partners before this launched, and according to OpenAI, that relationship steered the product toward investment banking and equity research as the starting point. The reasoning given was that reliable data access and producing high-quality output were the two biggest pain points those teams ran into.

Astra can reason through a DCF just fine on its own. The main problem is that a general chat model with no persistent access to properly entitled data, and no awareness of a firm's house style, produces something that feels right but falls apart the second a compliance reviewer looks at it. OpenAI mainly had to solve mostly a data and governance problem which looks like a model problem.

Nick Turley, OpenAI's VP of product, put it as teaching ChatGPT to research like an analyst and back up its conclusions the way an analyst would. I find that second half more interesting from a build perspective. Backing up conclusions means the product needs traceable citations baked in, not just fluent-sounding prose that are right most of the time.

The data layer

If I had to point at where the real engineering effort went, it's here. The product bundles GPT-6 Astra with premium financial data, templates a firm controls, and an enterprise governance layer sitting on top of all of it.

At launch, the built-in data comes from Daloopa, PitchBook, LSEG News, and Crunchbase, with Quartr also included according to reporting around the release. OpenAI indexes and hosts this data on its own infrastructure rather than calling out to each provider live every time, and the company says that choice improves retrieval speed, latency, and how reliably it can trace a generated claim back to its source. The product surfaces granular citations so a user can actually check a number against where it came from while they're working.

That decision to host and index the data themselves is a real architectural call, and I don't think it gets enough attention in the coverage. It trades a bit of data freshness for speed and citation accuracy. Building that means OpenAI had to stand up ingestion pipelines, work out freshness terms with each data provider, and build a citation layer that maps every claim the model makes back to a specific span in the source material.

For data a firm already pays for separately, the approach is different. Shared sign-in integrations with providers like S&P Capital IQ, LSEG, MSCI, Dow Jones Factiva, and Moody's recognize a user through their existing ChatGPT login and hand them access to whatever their firm already licenses. In practice that's federated identity plus entitlement pass-through. ChatGPT handles who the person is, and the data provider decides what they're allowed to see, so OpenAI doesn't have to rebuild every provider's access rules from scratch.

MCP connectors

For anything not built-in, the product depends on the Model Context Protocol, the open standard for connecting LLM applications up to external tools and data sources. OpenAI has specifically tuned MCP connectors for financial services reliability, and there are more than fifty available at launch, including Datasite, Box, Preqin, FactSet, and Intapp.

This matters if you're building your own tools rather than relying on what OpenAI ships out of the box, because the same MCP pattern is available directly through the API. Here's roughly what wiring an MCP-based data source into a Responses API call looks like:

const response = await fetch("https://api.openai.com/v1/responses", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${OPENAI_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "gpt-6-astra",
    reasoning: { effort: "high" },
    input: [
      {
        role: "user",
        content: "Pull the latest 10-Q filing data for this company and " +
                  "summarize the change in operating margin quarter over quarter.",
      },
    ],
    tools: [
      {
        type: "mcp",
        server_label: "financial-data-connector",
        server_url: "https://your-mcp-server.example.com/mcp",
        require_approval: "never",
      },
    ],
  }),
});
Enter fullscreen mode Exit fullscreen mode

Something I find genuinely interesting here is that OpenAI didn't hand-build fifty bespoke integrations for this one vertical. They standardized on MCP as the connector protocol and put their engineering effort into reliability tuning for the tool-calling patterns that actually show up in financial work: retrying calls that flake out, handling large tabular payloads cleanly, normalizing citations across providers whose data formats don't match. As a developer, that's reassuring, because the same protocol you'd use to hook up your own internal data source is the one the flagship product itself runs on. There's no closed integration format you're locked out of.

The governance layer

None of the security or compliance tooling here is finance-specific. It's the same enterprise stack OpenAI has been building for ChatGPT Enterprise for a while now, and financial firms just happen to be one of the more demanding customers for it. ChatGPT for Financial Services runs on top of ChatGPT Enterprise's existing SAML SSO, SCIM provisioning, and role-based access controls.

Pulling the full list together from what's been reported:

SAML SSO, SCIM provisioning, role-based access, configurable data retention, compliance-log exports, and separate workspaces for information barriers. Business data is encrypted at rest and in transit, and isn't used to train OpenAI's models by default. Firms can control which skills and connected apps are allowed to read or write data based on a user's role. Audit-log exports are available too, which matters a lot for anyone dealing with SEC or FINRA recordkeeping requirements.

Information barriers deserve a quick explanation if you don't work in this industry. It's the compliance concept of keeping, say, an M&A advisory team's data completely walled off from a public equity research team inside the same firm, so information can't leak in a way that becomes an insider-trading problem. Getting that right inside a shared AI product, where the same underlying model might be serving both teams at once, is a genuinely hard access-control problem. It's closer to multi-tenant role-based access with dynamic data segmentation than the kind of permissions system most SaaS products ship with.

Worth being honest about too: firms still have to configure their own access rules around what their users can see. OpenAI provides the scaffolding, the SSO, the RBAC, the audit logs, but the actual entitlement logic is on the customer to set up correctly. That's a fairly normal shared-responsibility model, but it's the kind of detail that gets left out of launch coverage and matters a lot once you're actually running this in production.

What's still unclear

I'd rather be upfront about the gaps than pretend I have the full picture:

Pricing hasn't been disclosed publicly, and neither has any minimum seat count, geographic restrictions, or the criteria OpenAI uses to decide which institutions get access. Right now this goes through OpenAI's sales team.

The product is also only available to select institutions so far, and it's focused specifically on investment banking and equity research rather than financial services as a whole. OpenAI has said the work with Morgan Stanley and Evercore will inform where it goes next, which reads to me like retail banking, insurance, and asset servicing use cases are still down the road, not part of this initial release.

And there's no independent audit yet on hallucination rates or citation accuracy specific to this product. The citation feature is a smart design choice, but it puts the responsibility on the human reviewer to actually check each one rather than trust the output outright. For financial work that's the right default to have, but it's worth saying clearly rather than assuming citations alone solve the accuracy problem.

The competitive picture

Anthropic already had its own version of this aimed at Wall Street, Claude for Financial Services, out before this launched. And OpenAI's CFO told investors back in August that their enterprise business now brings in more revenue than the consumer side does. I bring this up not to pick a winner, but because it tells you something about where this whole category is heading. It's going to come down to whoever builds the most reliable data and governance layer on top of a frontier model. At the very top end, the models themselves are close to interchangeable, trading wins on different benchmarks depending on the week. The actual differentiator is the less exciting stuff like entitlements, audit logs, citation integrity, and how well the output matches a firm's own templates.

Takeaways for developers

A few patterns from this launch are worth stealing for your own projects, regardless of whether you ever touch OpenAI's product:

If latency and citation accuracy matter to you, host and index third-party data yourself rather than making live calls out to external APIs every time. It's more work upfront, but it's the only way I've seen anyone get citations that actually hold up.

Standardize your tool-calling layer on MCP rather than writing a custom integration for every data source you need. It's what let this product scale to fifty-plus connectors without turning into an unmaintainable mess, and it keeps your architecture from getting locked to one vendor.

Treat entitlements as a core part of your design, not something you bolt on later. Figuring out which user can see which piece of data needs to happen at the data layer itself, especially once you've got multiple teams inside one organization that legally can't share information with each other.

And remember citations aren't free. If you want users to actually trust your output enough to act on it, you need a retrieval system that can trace every number back to a specific source span. A model that just sounds confident isn't the same thing.

I think it's a good reminder of what "enterprise AI product" really means once you cut past the announcement. It's a frontier model, a properly indexed data layer, a standard connector protocol, and a genuinely hard access-control problem, all wrapped around something a compliance officer is actually willing to approve. That combination is the real hard part.

Sources

For more such developer content, Click Here!

Top comments (0)