Stakeholder Registers for Multi-Jurisdiction Financial Services Programmes

The stakeholder register is the artefact teams maintain most casually and regret most acutely. It starts as a spreadsheet with 15 names, written in week one of the programme, and is rarely updated until someone important is missed out of a communication that should have gone to them. In a multi-jurisdiction regulated programme, the consequences of a stale register range from political embarrassment to material compliance gaps, because the stakeholders include regulators, senior managers with attested accountability, and second-line functions whose sign-off is mandatory.

This post covers how to build and maintain a stakeholder register that does its job in complex regulated scope. It draws on programmes that span multiple jurisdictions, multiple legal entities, and multiple regulators, where the stakeholder map is both more important and more work to keep current.

Why the register matters

A stakeholder register does four things in a programme of any size. It records who must be engaged, at what cadence, through what channel, and by whom. When it does these four things well, the programme moves smoothly. When it fails at any of them, the programme acquires the kind of friction that shows up as missed approvals, duplicated briefings, political flare-ups, and surprise objections at the steering committee.

In regulated programmes the register does two additional things. It provides the evidence trail for consultation obligations (who was consulted, when, and on what). It supports the change impact assessment by identifying which stakeholder populations are affected by which changes and how.

The structural elements

A useful register has nine fields per stakeholder. Fewer than nine and the register loses utility. More and it becomes administration for its own sake.

1. Identity

Name, role, organisation, jurisdiction. For regulators, the named supervisor. For senior managers, the SMF reference and the specific prescribed responsibility relevant to the programme.

2. Interest

Why the stakeholder cares about the programme. Expressed as a short statement of interest, not a generic "interested in project success". A regulator's interest might be "concentration risk in ICT third-party arrangements under DORA Article 29". A senior manager's interest might be "attestation under SMF 17 for money laundering reporting".

3. Influence

The stakeholder's ability to affect the programme, positively or negatively. A simple high/medium/low classification works. What matters is that it is applied consistently and reviewed as the programme progresses, because influence shifts with organisational changes.

4. Engagement level

Current engagement level and target engagement level. The commonly used scale runs unaware, resistant, neutral, supportive, leading. The target is what the programme needs from this stakeholder. The gap between current and target drives the engagement plan.

5. Channel

How the stakeholder prefers to be engaged: formal steering, working group, one-to-one, written brief, demo. Mismatching channels is a common friction: a stakeholder who expects a written brief receives a meeting invitation they do not attend, and concludes the programme is badly run.

6. Cadence

How often the stakeholder is engaged. Weekly, fortnightly, monthly, quarterly, event-driven. Cadence should match the stakeholder's decision-making cycle, not the programme's reporting rhythm.

7. Owner

Who on the programme is responsible for engaging this stakeholder. Without an owner, engagement defaults to "whoever is free", which produces inconsistent messages. Senior stakeholders have a senior owner. Groups of similar stakeholders have a shared owner.

8. Last engagement

Date of last meaningful engagement (meeting, written update, decision requested). Stakeholders who have not been engaged in more than one cadence period surface automatically as overdue.

9. Open commitments

What the programme has committed to delivering to or confirming with this stakeholder. Commitments tracked here become actions, which become decisions, which become the record that prevents "I was never told about that" conversations at steering.

Classification beyond the nine fields

In regulated programmes, stakeholders split along three additional dimensions worth tracking.

Line of defence

First-line (business), second-line (risk, compliance, data governance), third-line (internal audit). Each line of defence has different sign-off expectations and different interests. Mapping stakeholders to line of defence helps the programme route decisions correctly. A decision that requires second-line sign-off cannot be closed by a first-line stakeholder alone.

Regulatory jurisdiction

For multi-jurisdiction programmes, the jurisdiction the stakeholder represents matters because supervisory expectations differ. A firm operating in the UK (FCA, PRA), the EU (ECB, national competent authorities) and the US (Fed, OCC, FinCEN) needs to know which stakeholders speak for which regulator.

Attested accountability

Under the UK SMCR and equivalent regimes elsewhere, certain senior managers have formally attested accountabilities that cover the scope of the programme. These stakeholders cannot be omitted from material programme decisions without attestation risk. The register should flag them explicitly.

Engagement cadence by stakeholder type

The register is only useful if it drives engagement. The engagement plan that works in regulated programmes differentiates cadence by stakeholder type.

Regulators

Regulators are engaged through formal channels: supervisory meetings, regulatory returns, supervisory letters. Ad hoc engagement is inappropriate unless the firm's supervisor has explicitly invited it. The programme engages the regulator via the compliance function, not directly. The register captures the regulator for visibility, but the engagement plan routes through compliance.

Senior managers

Senior managers are briefed at a cadence that supports their decision cycle. For SMFs with programme-related accountabilities, the cadence is at least monthly and typically aligned to steering committee rhythm. Material decisions are pre-briefed before the committee, not surprised on the committee.

Second-line functions

Risk, compliance, data governance. These functions sign off on material artefacts (DPIAs, change impact assessments, control effectiveness reviews). Engagement is event-driven around the sign-off, with a standing cadence to surface emerging issues between events.

First-line operational stakeholders

The people whose day-to-day work is affected. Engagement is more intensive, more frequent, and more focused on the operational detail. Missing this population leads to the classic "launched on time, adoption at 30 percent" failure mode covered in our change management banking post.

External parties

Customers, vendors, partners, industry bodies. Engagement cadence depends on the contractual or market relationship. For DORA-critical third parties, engagement is formal and contracted.

Influence-interest mapping

The classic stakeholder matrix (high/low influence by high/low interest) remains useful in regulated programmes, with a specific caution: in regulated scope, a stakeholder with low interest but high influence (for example an internal audit function that is not actively engaged but can raise a finding) is still a mandatory engagement. The matrix guides tone and depth, not whether to engage at all.

The useful quadrants:

• High influence, high interest: manage closely. Formal, deep, frequent engagement.
• High influence, low interest: keep satisfied. Brief but informative engagement. Do not assume absence of interest means absence of concern.
• Low influence, high interest: keep informed. Regular updates, opportunities for input, but the decision remains elsewhere.
• Low influence, low interest: monitor. Do not forget them. Circumstances change.

Common failure modes

Failure: the register that ages silently

Written in week one, not updated. People change jobs. Senior managers hand over SMF responsibilities. Regulators rotate supervisors. The register still shows the old picture. Fix: the register is reviewed formally every two months minimum, and on every organisational change that affects the stakeholder map.

Failure: missing second-line stakeholders

The programme knows its business sponsor and its delivery team. It has not identified the compliance, risk and internal audit stakeholders whose sign-off will be required at go-live. By the time it realises, the sign-off becomes a critical path risk. Fix: identify the second-line stakeholders in week one, not at go-live minus four weeks.

Failure: the regulator handled ad hoc

The programme corresponds directly with the regulator without routing through compliance. The compliance function is surprised at the steering committee by a regulatory query it did not know about. Fix: all regulatory engagement routes through compliance, full stop. The register captures the regulator but the engagement line goes through the function.

Failure: the engagement that is only broadcast

The programme updates stakeholders but does not listen. Communications flow outward. Concerns and objections are not captured. The register shows the communications but not the responses. Fix: engagement is bidirectional by design. The register captures not just what was communicated but what the stakeholder said back and what commitments were made.

Failure: the forgotten external parties

Vendors and partners are not in the register. A programme change requires vendor cooperation. The vendor was not engaged, does not have capacity, and delays the programme by a quarter. Fix: contracted third parties with delivery dependencies are in the register with an owner and a cadence.

The register as a live programme tool

The register is most useful as an active operational tool. Four specific uses deserve explicit workflow support.

Decision routing

When a decision needs to be made, the register identifies who must be consulted, who must approve, and who must be informed. A structured routing query over the register surfaces the populations.

Change impact assessment

When scope changes, the change impact assessment uses the register to identify affected stakeholders and their engagement needs. New scope may introduce new stakeholders; the assessment is the point at which they enter the register.

Go-live readiness

Before go-live, the register is used as a checklist. Have all required stakeholders been engaged. Are all required sign-offs in place. Are there any overdue engagements with high-influence stakeholders. Go-live readiness reviews that skip the stakeholder check are setting up a surprise.

Post-go-live handover

Handover from the delivery team to business-as-usual includes handing over the stakeholder register. The register continues to serve the BAU owner, preventing the "restart" that otherwise happens when a new leader inherits a programme.

External references

The PMI PMBOK guide covers stakeholder management as a formal project management discipline. The APM Body of Knowledge covers stakeholder engagement from a UK project management perspective. For the regulated-programme specifics, the FCA expectations on SMCR accountabilities set the expectation for senior manager engagement.

The short version

The stakeholder register is one of the highest-leverage artefacts in a regulated programme and one of the most casually maintained. Nine fields, three additional dimensions for regulated scope, engagement plans that differentiate by stakeholder type, and the discipline to review the register on every organisational change.

A programme that invests in the register at the start, and updates it as a living artefact, has a materially lower risk of political friction and sign-off surprises. A programme that does not usually finds out why it should have at the steering committee three weeks before go-live.

Our change management and adoption service covers the stakeholder engagement workstream as part of the full adoption programme, and the business analysis service includes the register discipline as part of the delivery artefact stack.