Forward deployed engineering in financial services

This is the biggest segment for embedded engineering and the one where the environment constrains the work most visibly.

Why the sector concentrates this work

Two reasons show up in every engagement.

The environment is genuinely hard. Core systems that predate everybody in the room, data spread across systems that disagree with each other, and an integration surface with no coherent documentation. This is exactly the case where a plan written from outside meets reality in week six.

The consequences are asymmetric. A wrong answer is not a bug report. It is a customer complaint, a regulatory question, or a reportable event. That raises the cost of a system that is confidently wrong far above the cost of one that is slow.

Among 1,000 postings that named a target industry, financial services and banking led at 24 percent. AWS also named financial services explicitly as a focus area for its own forward deployed engineering organization.

The constraint: the audit trail

In most software, logging is a feature. Here it is a property of the design.

The question that gets asked is not whether the decision was correct. It is whether you can demonstrate how it was reached: what data the system used, which version of which rule applied, who or what made the call, and when. For an AI-assisted decision, add which model version, what it was given, and what it returned.

Why retrofitting is expensive. Adding an audit trail to a working system means finding every path that touches a decision and instrumenting it after the fact. Every path, including the batch job somebody wrote in 2019 and the manual override screen two people use. Missing one is worse than having none, because the trail now has a gap nobody can explain.

What that means for an embedded engineer. The audit trail is part of the week-one design rather than a later story. That sounds like it slows the first release and it usually does not, because the alternative is a rebuild once somebody asks the question.

Our financial software compliance guide covers the requirement side in depth, including the engineering translation of the rules.

The second constraint: change control

Getting a change into production in a bank is a longer path than in most companies, and the length is knowable in advance.

Change advisory boards that meet on a schedule. Security review. Penetration testing for anything customer-facing. Sometimes a model risk review with its own committee and its own cadence.

The engineering response is not to fight it. It is to ask, in week one, what has to be true for a change to reach production, who signs each step, and how long each has historically taken. Real durations rather than published targets. Then build the schedule around that answer rather than discovering it in month three.

This is why the first two weeks matter so much here: the release path discovery is worth more than the code written in the same period.

What tends to go wrong specifically

The pilot ran on an extract. A curated dataset behaves nothing like the production tables, and in this sector the difference is not cosmetic: it is the reconciliation break, the account in an unusual state, the record from a migration that predates the current schema.

Nobody defined the acceptable error rate. For an AI-assisted decision in a regulated process, this has to be an explicit number with an owner, because it will be asked about. Nobody volunteers to own it, which is why an embedded engineer has to force the conversation before production. Outcome-based pricing covers how to write it down.

The override path was an afterthought. In practice a human will overrule the system, and that override has to be captured, attributed and explicable. A system that cannot represent its own override is a system that will be switched off after the first contested decision.

Model risk review was not scheduled. The most predictable schedule slip in the sector and the easiest to avoid.

What an embedded engineer does differently here

Designs the audit trail with the data model, not after it.

Treats the override path as a first-class feature with the same rigour as the happy path.

Gets the acceptable error rate stated in writing, with a named owner, before production.

Maps the full approval path in week one and plans against real durations.

And keeps the checks independent of the model. Generated code is not secure by default, and in a regulated decision path the checks that prove behaviour have to be derived from the requirement and graded by something other than the model that produced the code. That is eval-driven development, and in this sector it doubles as the evidence a reviewer asks for.

The handover point that matters here

The inheriting team needs the eval suite more than the documentation, because in a regulated system the question is never only "does it work" but "can you still show it works after you changed it".

A handover consisting of an architecture document leaves the customer unable to modify the system without redoing the assurance work. A handover consisting of a runnable suite derived from the requirements leaves them able to change it and re-evidence it in an afternoon. Handover and exit covers the test.

Related: regulated industry software for the cross-sector view, and insurance for the adjacent case with its own state-by-state variation.