The Embedded BA

How a BA embedded with the bank links its stakeholders and the delivery team 

Nearshore delivery rarely drifts because engineers misread a ticket. It drifts because the bank's priorities move in rooms the delivery team isn't in: a steering committee that reorders the roadmap, a compliance review that narrows a product's scope, an operations team that changes how exceptions get handled on the back office floor. Each of these changes the shape of what should be built. If nobody carries that context from the bank's side of the table to the delivery side, the team keeps building yesterday's priorities very efficiently. 

The distance in nearshore delivery is rarely geographic. Iași and Vienna share a working day, and the team is a short flight away. The distance is organisational. Context lives with the bank's people, and delivery lives with the partner's people. The embedded business analyst is the role designed to close that gap: a BA who works inside the bank's business rhythm while staying part of the delivery team. Getting that role right is one of the clearest differences between a vendor that executes tickets and a partner that stays aligned with the business for years. 

Alignment is a structural problem, not a communication problem 

The usual response to misalignment is more meetings: an extra status call, a longer weekly report, another person copied on email threads. These add traffic without adding context, because the core issue isn't how often the two sides talk. It's that decisions get made in one place and the reasoning behind them doesn't travel with them. 

A user story arrives in the backlog saying the system should hold payments above a threshold for manual review. What doesn't arrive is that the threshold came from a fraud team's analysis of a specific corridor, that operations agreed to it only if the review queue stays under a set size, and that compliance wants the hold reason recorded in a form auditors can read. A delivery team without that context builds a correct feature that misses all three of those conditions. A BA who sat in those conversations writes them into the requirement before any code exists. 

That is the structural fix. Someone on the delivery side needs to hold the reasoning, not just the decisions. They also need the standing in the bank to keep holding it as the reasoning changes. 

What "embedded" actually means 

An embedded BA isn't a liaison who collects requirements once a sprint and forwards them on. In practice, embedded means three things. 

The BA works on the bank's calendar. They attend the business forums where priorities shift: product reviews, change advisory boards, risk and compliance check-ins, and the operations meetings where people describe how a process really works rather than how the procedure document says it works. They use the bank's collaboration tools and are reachable the way an internal colleague would be. 

The BA belongs to the delivery team. They run refinement, write and maintain acceptance criteria, answer engineers' and testers' questions the same day, and stay close enough to the code to know when a business request is a one-line change and when it touches the ledger. 

The BA translates in both directions. Business intent flows into precise specifications. Just as importantly, delivery reality flows back to the business in its own language. "The settlement service needs a schema change" becomes "this option adds two weeks and a data migration, while this other option ships on time with a manual step for one quarter." Stakeholders can only make good trade-offs when someone frames them that way. 

The artefacts that keep alignment durable 

Good intentions decay when people change roles. What makes embedded alignment last is a small set of working documents that the BA owns and keeps current. None of them is exotic. Their value comes from keeping them live and visible to both sides. 

A stakeholder map with decision rights. For each area of the product, it records who decides, who must be consulted and who simply needs to know. In a bank this almost always goes beyond the product owner to include compliance, operational risk, information security, the operations or back-office team, and often finance. When a question comes up mid-sprint, the map says who to ask, so the team doesn't have to guess or wait for the next steering meeting. 

A decision log. Each entry is short: the decision, the date, who made it, the options considered and the reasoning. This is the document that answers "why does the system behave this way?" eighteen months later, when the people in the original meeting have moved on. It is also the document auditors and internal control functions find most useful, because it links a behaviour in production to a business decision with a named owner. 

A shared domain glossary. Banks are full of terms that mean slightly different things to different departments. "Available balance", "settled", "customer" and "account closure date" can each have several working definitions across retail, treasury and operations. The BA keeps one agreed definition per term and notes where a department uses a variant. A large share of rework in banking delivery comes from two teams using the same word for different things, and a glossary catches that before it reaches the backlog. 

Acceptance criteria with a named business owner. Every requirement that reaches development has criteria someone on the bank's side has explicitly agreed to. That isn't a formality. It means the demo is a confirmation rather than a surprise, and "done" carries the same meaning on both sides of the partnership. 

Change impact notes. When a priority or regulation shifts, the BA writes a short note before anything enters a sprint. It covers what is affected, which completed work needs revisiting, what the options are and what each one costs in time and risk. Changes become decisions the business makes knowingly, rather than scope that quietly accumulates. 

Traceability from requirement to test to release. Each business requirement links to the tests that verify it and the release that delivered it. For a regulated institution this is not just good practice. When a bank relies on an external partner, it keeps full responsibility for the outcome. The EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) and DORA's provisions on ICT third-party risk (Article 28) are both clear on this point. Traceability the bank can inspect at any time is what lets it exercise that oversight without reconstructing it under pressure. 

The rituals that make the artefacts work 

The documents only stay current if they are part of how the work runs each week. A few practices do most of the work. 

Refinement with the business in the room. Backlog refinement includes the business owner for the stories being discussed, not just the delivery team. Fifteen minutes of a product or operations owner's time in refinement saves days of rework later. 

Demos framed as business outcomes. Rather than showing screens, the team walks through the scenario the business cares about, such as a held payment being reviewed, released and recorded, and checks it against the acceptance criteria that owner agreed to. 

A briefing before each steering meeting. Before each steering meeting, the BA prepares a one-page view of delivery status in business terms: what changed, which decisions are pending and which trade-offs need a choice. Steering time goes into choosing rather than catching up. 

A weekly business–delivery sync. One short, fixed meeting reviews new entries in the decision log, open questions for stakeholders and anything in the change pipeline. It replaces most ad hoc status requests. 

Continuity is where the value compounds 

An embedded BA becomes more valuable the longer they stay. In year one they learn the bank's products, its people and the unwritten rules of how decisions get made. By year two they can anticipate how a compliance team will react to a proposal, which operations constraints are fixed and which can be negotiated, and where an apparently simple request touches something fragile. That knowledge is hard to document fully and slow to rebuild. 

That's why continuity belongs in any evaluation of a nearshore partner. A partner who rotates analysts across clients every few months gives the bank the cost of embedding again and again without the benefit. A partner who keeps the same BA on an engagement and pairs them with a second analyst who can step in, backed by the decision log and glossary, gives the bank something that improves over time instead of resetting. 

What to ask a prospective partner 

For a bank assessing how a nearshore partner handles business alignment, a few questions separate a real practice from a slide: 

• Who on your side will attend our business forums, and how is their time split between our stakeholders and your delivery team? 
• Can you show an example of a decision log or change impact note from a past engagement, anonymised? 
• How do you keep a shared domain glossary, and who owns it? 
• What happens to business context when your BA goes on leave or moves to another role? 
• How do you show traceability from a business requirement to a released, tested change, in a form our internal audit function can use? 

A partner with an established practice will answer with concrete examples and documents. A partner without one will answer with the word "communication". 

The role that makes nearshore feel near 

Engineering capability is the price of entry for any delivery partner a bank considers. What determines whether a partnership is still working well three years later is whether the delivery team keeps understanding the business as it changes: new regulation, new products, new people in the decision seats. The embedded BA is how that understanding is maintained deliberately, rather than left to chance and goodwill. 

At OceanoBe, we have worked alongside banks long enough to see that the strongest engagements are designed this way from day one. Analysts sit inside the client's business rhythm, the working documents stay live, and continuity is planned rather than hoped for. Done this way, nearshore delivery stops feeling like a team somewhere else and starts working like an extension of the bank's own organisation.