FCA Complaints Reporting Rules and Timelines
Published
Most advice on FCA complaints reporting starts in the wrong place. It treats complaints as a service scorecard, then tries to bolt compliance onto the side. That framing is backwards. The FCA is asking firms to produce a regulatory record that can stand up to scrutiny, with the complaints register, outcome coding, redress, and closure timing all tied back to a defensible return.
That matters because the published figures are not just a market thermometer. The FCA's firm-level dataset sits inside a recurring reporting regime, with publication thresholds and half-yearly cycles that make the quality of each case record relevant to governance, not just to customer service. In practice, fca complaints reporting is a data architecture problem first and a reporting deadline second.
Table of Contents
- Rethinking Complaint Volumes as Regulatory Data
- Defining the DISP 1.10 Reporting Perimeter
- Mapping Required Data Fields and Classifications
- Navigating Reporting Cycles and Submission Deadlines
- Preparing for the PS25/19 Unified Return Framework
- Integrating Vulnerability Tracking into the Return
- Contextualising Firm-Level Data and Market Benchmarks
- Building Reconciliation Controls and Audit Trails
- Answering Board-Level Questions on Complaint Trends
Rethinking Complaint Volumes as Regulatory Data
A lower complaint count can be a warning sign, not a comfort. It may reflect genuine service improvement, but it can also come from weaker intake controls, faster closure before proper investigation, or inconsistent classification at the front end. The FCA's aggregate data shows why volume alone is too blunt, with 1.83 million complaints reported in 2025 H1, up 2.5% from 1.78 million in 2024 H2 (FCA aggregate complaints data for 2025 H1).
The true test is whether the firm can explain what changed in its products, channels, customer mix, or case handling. The same FCA publication also shows that around 57% of complaints were upheld in both periods, which means more than half of the cases firms closed were accepted as having merit under the firms' own assessments (FCA complaints data about data).
Practical rule: validate the reporting population before publishing any MI. If intake classification is unstable, a falling headline volume may be a classification artefact, not an improvement.
That is the operational point. Complaint reporting should sit alongside governance, remediation, and oversight because the return depends on clean joins between raw service logs, complaint registers, outcome coding, and closure timing. The FCA's firm-level publication threshold, together with market-wide aggregation, means a raw comparison never tells the whole story. A firm can look heavy on the page and still have a lower complaint rate once exposure is taken into account.
Defining the DISP 1.10 Reporting Perimeter
The first control is perimeter. Under DISP 1.10, firms must submit a complete complaints report for complaints from eligible complainants that concern activities within the Financial Ombudsman Service's jurisdiction where the complainant alleges actual or potential financial loss, material distress, or material inconvenience (FCA DISP 1.10 complaints data items FAQ). That definition matters because not every unhappy contact is a reportable complaint.
Build the perimeter at intake, not at close
The best firms flag reportable cases as soon as they enter the workflow. That means customer-service agents, call-centre scripts, web forms, and complaints teams need a shared definition of what counts as a complaint under DISP, rather than leaving the decision until the end of the period. A late-stage reclassification process almost always creates gaps.
Separate feedback from reportable complaints
General dissatisfaction, informal questions, and service requests should not automatically inflate the complaints register. The regulatory question is whether the customer is making an allegation that fits the DISP perimeter and whether the person qualifies as an eligible complainant. If the intake team cannot make that call consistently, the register becomes unreliable before the reporting work even starts.
Keep the case record auditable
Each case should carry the basis for inclusion or exclusion, the product or service category, the jurisdictional basis, and the date the complaint was received. That gives compliance a clear line of sight from the original contact through to the submitted return. If a case is excluded, the reason should be recorded, not left implicit.
Mapping Required Data Fields and Classifications
The FCA return is not a tally sheet. It needs case-level classification that links the original complaint to the product or service, the outcome, the timing, and any redress paid. In the standard format, firms use DISP 1 Annex 1R for ordinary complaints, DISP 1 Annex 1ABR for claims-management activity, and DISP 1 Annex 1ACR for regulated funeral-plan activity (FCA DISP 1.10 handbook rule).
A good internal design starts by matching the FCA taxonomy to the firm's own workflow fields. That is where many teams discover that their CRM is built for service handling, not regulatory reporting. A case may be closed operationally, but still lack the precise outcome coding needed for a return.
| FCA Data Category | Internal System Equivalent | Compliance Control |
|---|---|---|
| Complaint received | Intake record or case ID | Mandatory capture at first contact |
| Product or service category | Product taxonomy field | Controlled pick-list, no free text |
| Closure timing | Date received and date closed | Time-stamp validation |
| Uphold decision | Outcome code | Second-line review for consistency |
| Redress | Compensation or remedy field | Finance and complaints reconciliation |
| Exclusion reason | Non-reportable case marker | Documented eligibility check |
The reporting population should be built from the case record, not from an after-the-fact spreadsheet. If intake data, outcome data, and finance data sit in separate systems, the firm needs a controlled mapping process to reconcile them. The internal structure behind the return should be stable enough to survive staff turnover and system changes, which is why a complaints operating model needs the same discipline as other regulated data flows. For a broader view of how core systems shape control quality, see this discussion of banking core systems.
Where firms go wrong is not usually the final number. It is the hidden inconsistency between the case note, the classification field, and the redress ledger.
Navigating Reporting Cycles and Submission Deadlines
The FCA's timetable is fixed. Firms submit complaints data for six-month periods, and electronic returns must reach the FCA within 30 business days after the reporting period ends. That window is set out in the FCA's reporting timetable guidance, and it leaves little room for clean-up after month-end.
Close the books on complaints like a regulatory process
The firms that file cleanly run complaints reporting on a calendar with named owners. Operations freezes the population, compliance checks the inclusion rules, finance reconciles redress totals, and a senior approver signs off before submission. Parallel work without ownership usually leaves someone fixing an error on day 29.
Lock the data before the deadline pressure starts
Extraction needs to happen early enough for exception handling. A late pull from live systems creates version drift, especially when cases are reopened or redress is updated. The control objective is repeatable filing from a locked population, with punctuality as a by-product.
Use the deadline to enforce discipline
The 30-business-day window forces firms to separate operational closure from regulatory closure. That separation matters because it gives compliance a defined period to test whether the reporting population is complete, whether exclusions are justified, and whether the return matches the underlying register.
For teams that already manage regulatory submissions through structured controls, the pattern is familiar. For others, it exposes where manual workarounds have been hiding. The test is not speed on the final day, it is whether the data model, the case log, and the sign-off trail still align when the submission clock starts to run.
Preparing for the PS25/19 Unified Return Framework
The FCA's PS25/19 changes the architecture of complaints reporting by replacing five existing returns with one permissions-based return and fixed reporting cycles for all firms (FCA PS25/19 consultation and policy paper). That sounds simpler, but it also forces firms to rethink how permissions map to data fields, especially where one legal entity carries several regulated activities.
Migration is only half the task. The harder work is mapping legacy Consumer Credit, Payment Services, Funeral Plans, and Claims Management data into the new structure without breaking comparability. Firms with mixed permissions need a permission-to-field matrix that shows which team classifies each complaint, where it sits in the return, and how the case moves through validation. Without that control layer, the same complaint can be counted differently by different operational teams.
Smaller firms still need the machine
Low volume does not mean low exposure. The reporting obligation still applies even where complaints volumes may fall below the publication threshold used for firm-level disclosure. Smaller firms therefore need the same architecture for data capture, mapping, and sign-off, even if their public footprint is limited.
Build for permissions, not just products
PS25/19 pushes firms towards a permissions-based view of complaints. That requires a cleaner split between activity type, legal entity, and reportable field. Teams that have historically relied on broad product labels often find that those labels are too blunt for the new framework. Start with permissions, then map each case to the return field that matches the regulated activity and the reporting perimeter.
The practical payoff is consistency. A unified structure reduces the risk that the same complaint is treated differently by different business lines. It also makes later returns easier to compare, because the reporting basis depends less on local interpretation and more on a controlled data model.
Integrating Vulnerability Tracking into the Return
Vulnerability data cannot sit beside complaints as an afterthought. The return now needs to capture complaints where the firm has identified the customer as vulnerable, and complaints about a failure to consider or respond to vulnerability. That creates a reconciliation problem, because a single case may carry both a service issue and a treatment issue. The data model has to keep those fields separate while still letting the firm explain the full case history.
Tag vulnerability at case level
Front-line teams need a structured vulnerability field, not free text alone. If a case is tagged only in narrative notes, the reporting team cannot aggregate it with confidence, especially where multiple channels feed the same complaints queue. A clean case-level marker gives compliance something auditable, and it reduces the risk that local wording drives inconsistent reporting.
Avoid double counting
A complaint from a vulnerable customer is not the same as a complaint about a missed vulnerability response. Firms should code both where both facts exist, then prevent those flags from inflating the headline volume. For example, if a customer says the complaint was mishandled because staff missed a vulnerability marker, the case may belong in the vulnerability field and the root-cause field. The first records who was affected, the second records what failed. Controls should stop analysts from counting the same issue twice while still preserving both dimensions for review.
Align treatment and reporting
The reporting flow should mirror the treatment flow. If the front-line team identifies vulnerability early, that assessment has to move into the complaints record without being reinterpreted later by a separate reporting team. The firm should be able to show who made the tag, what evidence supported it, and why the final code was used. FG21/1 is a useful reference point for that discipline.
Useful standard: if the front-line team can't explain why a case was tagged vulnerable, the reporting team shouldn't inherit the tag.
Contextualising Firm-Level Data and Market Benchmarks
Public FCA complaints data only covers firms that cross the reporting threshold, 500 complaints in a six-month period, or 1,000 annually where the annual consumer-credit return applies (FCA complaints data about data). That matters because a published league table is not the market, it is a filtered slice of it. Compare firms carefully, or the ranking can create false comfort or unnecessary alarm.
Market totals give a better benchmark, but only if the comparison period is correct. In the second half of 2025, the FCA recorded 1.74 million complaints, compared with 1.83 million in the first half, a decline of about 4.9%. Banking and credit-card complaints made up 857,757, while investments accounted for 54,280. Those numbers are a useful reference point, but they still need context from the firm's own customer base, channel mix, and product profile.
A board should ask three questions before it reacts to a trend. What is the customer base size? What is the transaction or policy volume? What changed in product mix or channel mix? Without those denominators, a higher complaint count may just track business growth, not weaker service. For wider governance context, this overview of UK financial-services regulation is a useful companion.
Use the FCA view and the management view together
Internal dashboards should show absolute volumes, upheld rates, timeliness, product splits, and root causes. The FCA publication uses a different lens, shaped by threshold rules and regulatory taxonomy. Those views should sit side by side in the control pack, then be reconciled back to the same source records.
Read the trend, not just the headline
If banking complaints rise while overall volumes stay flat, the first question is what changed in that product group. If investment complaints move differently, check whether the issue sits in distribution, advice, or post-sale administration. Context matters more than alarm, and it is the only way to turn complaint data into a defensible management signal.
Building Reconciliation Controls and Audit Trails
A defensible return needs a defensible trail. Reconciliation starts by tying the FCA submission back to the complaints register, the case notes, and the approval record, in line with the record-keeping expectations set out in the FCA complaints data items FAQ. Without that, the return is just a spreadsheet with a filing date on it.
Reconcile from source to submission
The bridge should be line by line. For each complaint, it should show the case ID, whether it was included, the exclusion reason code if it was left out, and any redress amount attached to the record. That level of mapping is what lets a compliance team prove that the submission reflects the source population, not a filtered version of it.
A good bridge also exposes where judgement entered the process. If a file was excluded because it fell outside the reporting perimeter, that decision should be visible in the control pack, together with the rule used and the reviewer who applied it. Teams that want a wider view of the control environment can pair this with FCA compliance requirements guidance, but the operational test stays the same, every reported line must be traceable.
Keep management review evidence
The approval trail should show who reviewed the return, when they reviewed it, and what they challenged. Initials, timestamps, and note references are more useful than a vague sign-off, because they show how issues were resolved, not just that someone clicked approve. In practice, that evidence is often the difference between a clean supervisory conversation and a harder one.
Treat corrections as part of the control, not an exception to it
If an error surfaces after submission, the firm should be able to trace it back to the source record, explain the cause, and show the amended treatment. That requires a control log that captures the original classification, the correction, the approver, and the date the fix was made. Strong audit trails reduce rework and make remediation easier to defend.
Answering Board-Level Questions on Complaint Trends
Boards often ask for the wrong summary. “Are complaints up?” is too blunt. “Did we close them faster?” can be just as misleading if speed came at the cost of investigation quality or if the team started reopening cases later.
The better question is which signal changed and why. A rise in upheld complaints can point to stronger issue detection, not just worse conduct. A rise in vulnerability-related cases can reflect better identification, not necessarily poorer treatment. Complaints data needs to be segmented by product, channel, root cause, and outcome before anyone draws conclusions.
Choose the metric that matches the decision
If the board wants to know whether the customer journey is improving, raw volume is only one input. If it wants to know whether controls are working, upheld rate and root cause matter more. If it wants to know whether the firm is under-reporting, reconciliation quality and case classification deserve the spotlight.
Avoid optimising one line at the expense of another
A push for faster closure can reduce backlog, but it can also flatten the investigation. Better vulnerability tagging can make the numbers look worse before they look better, because the firm is finally seeing what it previously missed. That is not deterioration, it is visibility.
Give the board a decision pack, not a scoreboard
The board pack should show where the cases came from, how they were categorised, what redress was paid, and what remediation or process change followed. That turns complaints reporting into a management tool rather than a compliance ritual. For the right governance mindset on regulatory readiness, this discussion of FCA approved person readiness is worth a look.
Glentorion helps firms turn regulatory requirements into structured, defensible operating models, from case classification and reconciliation controls to submission readiness and management interview preparation. If your team needs to strengthen its FCA complaints reporting process or align systems with the unified return, visit Glentorion to explore how its consultants and engineers support authorisation and governance work.
- FCA complaints reporting
- DISP rules
- regulatory compliance
- complaints data
- FCA returns
