Regulatory Deadline With a Moving Target
A financial services firm must comply with a new reporting regulation in nine months. You are the business analyst on a programme with three workstreams: data sourcing, report generation, and a change to the customer onboarding process. The regulator has published draft rules but may issue final guidance four months before the deadline. The programme manager wants a full requirements baseline signed off in month two so development can start. The data workstream reports that two source systems hold conflicting customer identifiers and no reconciliation rule exists. Compliance says "just build what the regulation says" but cannot yet confirm interpretation of two key definitions.
1. How should you plan the requirements lifecycle given the regulatory uncertainty?
Read the worked answer
Do not force a single big-bang baseline. Plan for staged, version-controlled baselines:
- Baseline what is stable now - data sourcing needs, report structure where rules are clear, and onboarding process changes that do not depend on the disputed definitions.
- Hold the two disputed definitions as open items with owners in Compliance, and model the likely variants so design can proceed without committing.
- Use a tracer bullet approach for the report workstream: build a thin end-to-end version early to expose data and interpretation issues.
- Plan for re-baselining at the point final guidance is expected (month five), with impact analysis built into the schedule.
- Apply requirements attributes - source, owner, stability and priority - so the impact of regulatory change can be assessed quickly.
- Agree change control in advance: who assesses regulatory impact, how quickly, and what the tolerance is.
A baseline in month two is achievable for stable scope only. Promising a complete baseline invites rework and false assurance to the regulator-facing sponsor.
2. The two source systems hold conflicting customer identifiers with no reconciliation rule. What analysis do you do, and who decides?
Read the worked answer
This is a data quality and business rules problem that must be resolved before report requirements can be finalised.
Analysis steps:
- Profile the data - how many records conflict, in what patterns, and what the business consequence of each resolution is (for example, misreported exposure or duplicate customers).
- Identify candidate rules - for example, source precedence, most-recent-value, or a matching algorithm with a confidence threshold.
- Assess each rule's impact on regulatory reporting accuracy and on operational processes.
- Model the data to show where the identifier is used downstream, so the blast radius of a rule is visible.
Decision ownership: the rule is a business rule, so the accountable business owner (likely Compliance with Data Management) decides, informed by your analysis. You do not choose the rule; you make the choice explicit, evidenced and recorded.
Document the agreed rule with its rationale, owner and date, and trace report requirements to it. Where no rule can be agreed in time, propose a documented interim rule with a review date and flag the regulatory risk to the sponsor.
3. Compliance says 'just build what the regulation says.' How do you respond?
Read the worked answer
Acknowledge the intent - compliance is the objective - but explain why the instruction is not yet actionable. Regulations state outcomes and definitions; they rarely specify system behaviour. Two key definitions are unconfirmed, so 'what the regulation says' is currently ambiguous.
Respond by:
- Converting the regulation into a traceable set of obligations - each clause mapped to the business processes and reports affected, with interpretation notes.
- Separating obligation from interpretation. The obligation is fixed; the interpretation is a decision Compliance owns. Present the disputed definitions with options and consequences so Compliance can decide rather than defer.
- Offering a working interpretation for design purposes, clearly marked provisional and subject to confirmation, so the programme is not blocked.
- Escalating the risk of late final guidance to the sponsor with a mitigation plan.
This respects Compliance's authority while giving them a concrete decision to make. Simply building an interpretation without their sign-off transfers regulatory risk to the delivery team, which is unacceptable.