FCA complaints reporting: test the data before January 2027
A complaints log can look complete until someone tries to turn its entries into a regulatory return. A product description sits in free text, a customer’s support needs appear only in correspondence, or two teams use different names for the same issue. Finding those gaps now gives the people who capture the information time to change their approach.
For firms affected by the FCA’s unified complaints return, collection of the required individual data points starts on 1 January 2027. The first reporting period covers January to June 2027. Confirm your firm’s position under the applicable DISP reporting rules and permissions; this is not a blanket requirement for every authorised firm.
Our suggestion is to trace five deliberately different complaints through your proposed reporting process. This is an RRCA diagnostic exercise, not an FCA sample requirement or evidence that the whole population is compliant.
Start with the fields your team actually completes
Put the relevant return requirements beside your current complaints log. For each required field, identify where the information originates, who records it and how it reaches the report. Ask a handler to demonstrate the route using a case they understand.
Keep the test concrete. If the report needs a classification, can the handler select it consistently at the right point in the case? If another team supplies a value, who checks that it arrived? Record any answer that depends on someone remembering a workaround.
Use the current future-dated Handbook requirements. The FCA has flagged subsequent amendments for targeted support and Deferred Payment Credit, so the original policy statement alone is not a sufficient specification for every firm.
Choose five files that challenge the process
Select a small, varied set: for example, a straightforward closed complaint, an unresolved case, one spanning more than one issue, one involving identified vulnerability and one involving another business or legal entity. Use the cases you actually have; do not invent a missing category just to complete the exercise.
Ask two colleagues to classify the same files independently, then compare their decisions and supporting reasons. A disagreement is useful: it identifies wording, guidance or training that needs attention before the full reporting cycle begins.
For each file, keep a short test record containing its internal reference, expected result, actual result and any difference. Use references rather than copying unnecessary customer detail. Five clean examples cannot establish that the wider dataset is sound; repeated problems should prompt a broader, risk-based check.
Keep the vulnerability questions separate
The new reporting approach distinguishes complaints involving a customer identified as being in vulnerable circumstances from complaints about a failure to consider or respond to vulnerability. Check how the applicable return captures both dimensions.
Consider a hypothetical policyholder, already identified as vulnerable, complaining about an unrelated administrative charge. Their circumstances do not by themselves establish that the complaint concerns a failure to respond to vulnerability. If the complaint instead concerns the firm’s failure to provide agreed support, that may change the assessment. The decision needs to follow the evidence and relevant reporting guidance.
Test whether your records preserve that distinction. A single unexplained flag may leave the reporting team unable to tell what was assessed. Ask handlers to show the supporting case note and explain how a later correction would reach the reporting dataset.
Trace the figures to the right legal entity
The unified return removes group reporting: submission is at individual legal-entity level. A shared complaints team therefore needs a dependable way to identify which entity’s report each case belongs in.
In the sample, trace that decision from the underlying record to the proposed reporting output. Where a case involves another firm, check the applicable reporting treatment rather than allocating it solely from a brand name or the team that handled it.
Then reconcile your test output to its source records. If a file is omitted, counted twice or allocated differently by two teams, record the cause and owner. A total that balances overall can still conceal an allocation error.
Leave the exercise with a dated repair list
Turn each finding into a specific change: a capture field, a classification definition, an entity-allocation rule, a system mapping or a short handler briefing. Assign an owner, completion date and retest. Check the revised process with fresh examples rather than simply confirming that a document was updated.
Add the reporting timetable to that plan. The future DISP rules use January–June and July–December periods, with reports generally due within 30 business days after period end. Check any applicable transition arrangements, including a shortened final old-format period. Data collection needs to work from January; the later submission window is not extra implementation time.
If the exercise exposes uncertainty about your reporting approach, RR Compliance Associates can discuss a focused compliance review. Where the gap is staff understanding, our training and workshop options may help reinforce the agreed process. Neither replaces the firm’s responsibility to establish accurate reporting.
Five-file diagnostic worksheet
Purpose: expose practical gaps in the proposed data capture and reporting process. Five files is an illustrative RRCA starting point, not a prescribed FCA sample size, a complete audit or assurance of compliance. Confirm the reporting rules and permissions relevant to the firm before using this worksheet.
Review details
Legal entity / reference:
Reviewer(s):
Review date:
Applicable requirements / version checked:
Proposed reporting process / version:
Choose the sample
Select deliberately varied cases available within the firm, for example:
A straightforward closed complaint.
An unresolved complaint.
A complaint spanning several issues.
A complaint involving identified vulnerability.
A complaint involving another business or legal entity.
Record why each was selected. Categories may overlap; missing examples remain a test limitation, not fictional files.
Repeat for each file
Internal file reference:
Reason selected:
Expected classification and evidence:
Actual classification and evidence:
Where each required data point is captured:
Who captures it / when:
Route into the reporting output:
Identified vulnerability and supporting assessment:
Separate assessment of any failure to consider/respond to vulnerability, where relevant to the applicable return:
Reporting entity and allocation rationale:
Any forwarding or shared-responsibility issue to check against the rules:
Reconciliation result: correctly included / omitted / duplicated / other:
Second reviewer's classification and reason:
Difference or unresolved question:
Turn findings into actions
Finding:
Cause: capture / guidance / training / mapping / allocation / other:
Required change:
Owner:
Due date:
Retest example(s):
Retest result and evidence:
Remaining limitation / wider review required:
Decision
What can this small test support?
What remains untested?
Do the findings justify a broader check?
Who has accepted the next steps, and when will progress be reviewed?
Use internal references and avoid copying unnecessary personal information into this worksheet. Keep it with the firm's controlled review records.
Source context: FCA Reporting complaints (updated 25 September 2026), PS25/19 chapter 3, and the applicable future-dated DISP reporting requirements. The testing method and worksheet are RRCA practical suggestions; they do not replace the rules.
Sources
FCA: Reporting complaints — updated 25 September 2026.
FCA: PS25/19, implementation arrangements — December 2025, chapter 3.
FCA Handbook: DISP 1, future version dated 31 December 2026 — including DISP 1.10.4 and 1.10.5.
Comments