New product, new returns — the scoping questions
The most common cause of a reporting defect is not a bad calculation. It is a product that launched without anyone asking what it did to the returns. A new product can change a reporting population without changing a single field definition — and when it does, the return is short with nothing in the output to indicate it. Four questions asked before launch prevent almost all of it.
1. The four questions
| Question | What it detects |
|---|---|
| Does it create a new population? | Accounts, exposures or transactions that belong in an existing return but are not yet mapped into it |
| Does it introduce a new instrument or product type? | A classification decision that must be made once, centrally, and recorded |
| Does it introduce a new counterparty class or geography? | A perimeter change — potentially bringing a whole new return into scope |
| Does it need customer attributes we do not collect? | An onboarding change, which is cheap before launch and a remediation programme after |
2. Why it fails silently
A product added to the business and not to the reporting mapping produces a return that validates cleanly. Every rule passes, because the rules test the internal consistency of what was submitted — not whether the submission covers everything it should.
That is why the only reliable detective control is a reconciliation to the ledger or, where a return has a granular counterpart, a granular-to-aggregate check. Both compare the reported population against an independent view of what exists, and both will show a new product that never arrived. Validation rules never will.
The secondary signal is reconciling-item drift: a definitional difference between two returns that starts growing is usually a product that reached one pipeline and not the other.
3. What “changes the perimeter” looks like in practice
Four concrete cases, each drawn from a regime covered elsewhere on this site:
- Adding a credit feature. An instalment or overdraft product creates credit exposures, which can bring a firm into a national credit register — the Spanish one names payment and e-money institutions expressly where they carry on the relevant credit activity.
- Serving a new country’s residents. Several obligations attach to the customer’s residence rather than to establishment, so organic growth into a neighbouring market can trigger a return with no regulatory event marking it.
- Adding a new payment instrument. Fraud and payment statistics are reported by instrument, so a new instrument means new reporting lines — and a fraud dataset built around one instrument’s reason codes cannot populate them.
- Adding an ICT provider. A new supplier supporting a critical function changes the register of information and may trigger an advance outsourcing notification.
4. Where the gate belongs
The scoping question has to sit in the product governance process, not in the reporting calendar — because by the time a reporting cycle notices, the product has been live for a quarter.
What works is a single mandatory item in the launch checklist, answered by the reporting function rather than by the product team, with three possible outcomes: no reporting impact (recorded, with a reason); mapping change required (with an owner and a date); or perimeter change requiring assessment (which may hold the launch date). The third outcome is rare and is precisely why the gate exists.
5. A worked case
Facts: a firm launches a shared-account feature allowing a second person to transact on an existing account. Product treats it as a permissions change.
What it actually is: a change to the connected persons on an account, with a role. Account registers in several markets require connected subjects to be declared with their role specified, and at least one treats a change to connected persons as a declarable modification event distinct from opening and closing.
What the practitioner does: maps the new role to the register’s role codes before launch, extends the event feed so a permissions change emits a modification where required, and confirms the onboarding flow captures the second person’s identification data to the register’s standard — which, for a feature framed internally as “permissions”, nobody would otherwise have checked.
FAQ
Why don’t validation rules catch a missing product?
Because they test the internal consistency of what was submitted, not whether the submission is complete. Only a reconciliation against an independent population view detects an omission.
Which question matters most?
Whether the product changes the perimeter — a new counterparty class or geography can bring a whole new supervisor, channel and enrolment into scope.
Where should the check live?
In product governance, as a mandatory launch-checklist item answered by the reporting function. A reporting-cycle check notices a quarter too late.
Related: Reporting at market entry · Mapping source data · Reporting data quality metrics
