The hard part of AI in banking stopped being the model a while ago. Any institution can buy access to a frontier model this afternoon. What almost none of them can do is integrate that model into a core system, wire it into an existing control framework, produce an audit trail an examiner will accept, and keep it running after the vendor’s slide deck is closed.
That gap is where a job title from a different industry has quietly become the most important thing happening in fintech AI: the forward-deployed engineer.
What a forward-deployed engineer actually is
The model is not new. Palantir built its business on it more than a decade ago, sending engineers to sit inside client organizations and write production code against the client’s real data and real problems.
A forward-deployed engineer, or FDE, is not a sales engineer. Sales engineers sell. It is not an implementation consultant, who configures a product that already exists. It is not customer success, who manages the relationship after the fact. An FDE writes code inside your infrastructure, against your systems, to solve a problem that did not have a product yet.
In financial services, that job requires a second set of skills that generalist AI engineers do not have. Monetary precision and rounding behavior. Payment idempotency. Keeping a workload out of PCI DSS scope, or knowing when it cannot be. KYC as a state machine rather than a checkbox. Enough regulatory literacy to know which design choices create examination risk.
An excellent engineer from a frontier AI lab is not the same thing as an engineer who has shipped inside a bank. The distinction matters more than the résumé suggests.
The shift: two platforms absorbed the cost
Until recently, getting FDE-grade help meant hiring it directly, and the price reflected the scarcity. That is changing, and the mechanism is worth understanding.
According to vendor announcements from May 2026, two of the largest core and payments platforms embedded AI partner teams inside their own organizations rather than inside their clients’:
FIS with Anthropic. Anthropic’s applied AI team working alongside FIS engineers on a Financial Crimes AI Agent for AML workflows, with BMO and Amalgamated Bank named as pilot institutions and general availability targeted for the second half of 2026. FIS has described the arrangement as a knowledge transfer, with the goal that FIS builds subsequent agents on its own.
Fiserv with OpenAI. Joint teams supporting an agent marketplace layered onto the Fiserv platform, with community institutions among the early participants.
The structural consequence is what matters. Neither arrangement puts an engineer inside a $400 million community bank. It puts them inside the vendor that thousands of community banks already run on. The cost of the specialist gets amortized across the entire client base instead of billed to one institution.
What that changes for a community bank
You can get capability you could not have built. A financial crimes agent arrives as a platform feature rather than a six-month project with a consulting line item attached. For an institution with a two-person IT department, that is the difference between having the capability and not.
Governance is being designed in, not bolted on. Both vendors describe audit trails, policy enforcement, and human-in-the-loop decision rights as part of the architecture. That is a meaningfully better starting position than the retrofit most institutions would have attempted on their own.
Somebody else is making your design decisions. This is the part that gets less attention. Amalgamated Bank sent its compliance team to help shape the FIS agent. BMO is in the pilot. Your institution almost certainly is not. The risk tolerance, the alert thresholds, the definition of what warrants a human review, all of it is being set by the pilot banks, and those banks are considerably larger than yours.
That is not a scandal. It is how platform software has always worked. But it means the correct posture is not “wait and see what ships.” It is to understand the design decisions before they arrive, so that when the feature turns on you already know which defaults do not fit your institution.
Three things to watch
Lock-in is design lock-in, not just contract lock-in. Switching cores is a known cost. Discovering after general availability that your AML agent embeds a larger bank’s risk appetite is a different and less visible problem, and re-architecting it after the fact is expensive.
Ask what happens when the embedded team cycles off. The question worth putting to any vendor: after the forward-deployed team leaves, can your organization still operate, monitor, challenge, and safely modify this workflow? For a platform client, “leaves” means the AI partner’s engineers finish knowledge transfer and move on. Whether the vendor genuinely absorbed that capability, or simply became dependent one layer up, is not knowable from a press release. Ask anyway, and ask again in a year.
The cost was amortized, not eliminated. FIS and Fiserv are paying real money for these teams, and it appears somewhere: licensing, per-agent fees, or the pace of the next feature. Frontier AI inside a regulated institution carries an integration overhead that no announcement removes.
The tell for buyers
Here is the practical version, and it is the most useful sentence in this piece.
If a fintech vendor approaches your institution in the next twelve months offering an “embedded engineer” or “forward deployment” as part of the package, price it against what that engineer actually costs. FDEs who are good enough to embed inside a bank are senior engineers, and senior engineers who understand both AI systems and banking regulation are among the scarcest labor in the industry right now.
A cheap forward deployment is not a bargain. It is a short one. The engagement ends, and what is left behind is a system nobody in the building fully understands.
That is the same failure mode we keep coming back to: a capability arrives without anyone deciding to adopt it, and the institution inherits an architecture it did not choose. The FSB’s Sound Practices framework has a word for the step that prevents this. It is called selection, and it assumes somebody in your institution actually made one.
Upstate AI works with community banks and credit unions on AI strategy, vendor evaluation, and governance. If you are evaluating an AI feature from your core provider, we can help you ask the right questions before it turns on.