FSCS SCV Regulatory Update March 2021
New Changes in FSCS Single Customer View Regulatory Reporting
As you all aware Regulatory Reporting landscape changes quite often with ever-changing metrics and KPI’s with constant demand from the authorities considering market dynamics & business changes which mandate a high level of adherence.
FSCS has announced changes in its SCV reporting specifications and Macro Global has analysed their possible impact across the reporting and other dependent data sets within SCV. In our view, these changes bring more clarity and enhancements to make things easier for both banks and FSCS.
Macro Global is already working on making those changes into our scheduled release in the next few weeks across all our clients. For further queries, write to us at 24x7support@macroglobal.co.uk with the subject as “SCV Changes 2021”.
FSCS is now accepting SCV output files with two more file formats where the bank can submit their SCV files using the two new formats. The New file formats are Excel & XML. These new File format specifications are explained on FSCS Single Customer View website.
FSCS accepts the following file types :
- Excel – .xlsx (old .xls and macro-enabled spreadsheets are not accepted)
- XML – .xml
- Text – .txt or .csv
Accounts held by UK or Gibraltar branches are only protected by FSCS. This change affects the Account Branch Jurisdiction must be either GBR or GIB in the SCV or Exclusion view file.
Protection removed for EEA branches of UK deposit takers
From the end of the transition period (11 pm on 31 December 2020), deposits held in EEA branches of UK deposit takers are no longer be eligible for compensation by FSCS. The EEA include the 27 EU Member States along with Norway, Iceland and Liechtenstein.
Account Details
| Field Name | Field Description | Data Type | Max. Field Length | Example | Contents Mandatory? |
|---|---|---|---|---|---|
| Account Branch Jurisdiction | Eligible deposits must be held by UK or Gibraltar establishments. State “GBR” or “GIB”, as applicable. | Alpha | 3 | GBR | Yes |
If the reporting customer has a BFPO address, then the BFPO number should be present in Address line 6. Postcode must be present in the postcode field. The country field must be blank.
You can find government guidance on address formats for BFPOs here:
https://www.gov.uk/bfpo/how-to-address-bfpo-mail.
Ensure the BFPO number is in the final line of the address and leave the country field blank.
If an address has a BFPO postcode instead of a BFPO number, enter the BFPO postcode in the Postcode field.
If any of the reporting customer address is related to the care of address then the C/O must be present in the address line 1 or address line 2 as follows.
- “Care of Mr XXX”
- “C/O Mr XXX”
Alternatively, a specific account status code like “COA” can be assigned to the customer accounts who are having a care-of address.
These care of address customer accounts now can be reported in NFFSTP. If there is any reason you want those customers to be reported in NFFSTP then the bank can report those customer accounts in NFFSTP. If new status code(s) introduced for this purpose then those should be available in the account status code section of the effectiveness report.
If the reporting customer has a phone number(s) then those details should be in the Main phone number, Evening phone number or Mobile phone number fields. If the reporting customer has an email address, then it should be available in the email address field only.
The phone numbers should be formatted without spaces, hyphens or + signs. If it is an international number, then the phone number(s) should be prefixed with 00 instead of + sign.
FSCS has introduced a hierarchical order for the exclusion types where an account is supposed to be assigned with multiple exclusion types then the bank must select one from the hierarchy for that particular account.
Exclusion View File
- HMTS
- LEGDIS
- LEGDOR
- BEN
Accounts cannot appear in both the SCV and Exclusions View file. Legally Disputed, Legally Dormant and Beneficiary classifications apply at an account level.
FSCS has now proposed to not report the same account in SCV and Exclusion view files. Customer may be present in SCV and Exclusion. But account should not exist in SCV and Exclusion view file.
FSCS has now instructed to put 001 in the Account Hold Indicator field for the Beneficiary account(s).
FSCS has now instructed, the bank must manage the legally disputed accounts at the account level, not At the customer level.
How should I treat cases where, for example, a depositor has 4 eligible accounts and one of these is under legal dispute?
If an account is a joint account and any one of the account holders is sanctioned then the other account holders who are not sanctioned should also be placed in the exclusion view file. If that particular non-sanctioned account holder has another account, then that particular account can be placed in the SCV file.
How should I treat a depositor who is has a joint account with a sanctioned individual?
As per the new FSCS guideline, the Legally Dormant accounts will be treated where all the account holder to that account should be placed in the exclusion view file.
How should I treat joint accounts if one account holder is Legally Dormant? For example, Mr. Smith has a sole account with Bank B. He also has a joint account with Mrs. Smith at Bank B, which hasn’t been used for over 15 years. Mrs. Smith hasn’t contacted Bank B in this time. How should Mrs Smith be treated?
Legal dormancy applies at an account level rather than at the depositor level. So, in the above example, Mr. and Mrs. Smith’s dormant joint account should be put into the Exclusions View file, and Mr. Smith’s solo account should be put into the SCV file.
SCV Alliance
FSCS SCV Audit Platform
SCV Forza
FSCS SCV Automation Platform
Provide utmost accuracy and Complete Peace of mind
We will be able to help you in whatever the stage of your regulatory reporting programs
Why Banks need FSCS SCV Regulatory Compliance Reporting Tool?
An ever evolving and more stringent FSCS regulatory compliance landscape with increased reporting and risk oversight, demands a sophisticated single customer view reporting tool for financial services firms around the globe.
It’s difficult for banking technology teams to keep up as banks are generating and analysing more customer data than ever before due to initiatives in global derivatives regulation.
Adding to the demands of FSCS regulatory compliance, many of the existing FSCS SCV regulations require changes to transaction formats to standardise processing and reporting.
“Banks are likely to spend more than $8 billion in the next six years to improve technology platforms to meet demands to beef up how they manage and report risks”. – Sungard
Financial institution’s data across the organisation in siloed applications and data stores and sharing data between different parts of their banking institution is difficult and requires manual effort every time data is shared.
Because of these data and organisational silos, FSCS regulatory compliance reporting usually entails transferring information from multiple systems into a centralised data repository, creating more data in the process.
The process of extracting, aggregating, standardising, and reconciling data for regulatory and compliance purposes increases the risk of poor data quality and inaccurate reporting, which can spell trouble for financial institutions.
Our SCV Alliance – FSCS SCV Audit solution helps you to identify inaccuracies and put processes in place to prevent penalties and ensure that your data is duplicate free, consistent and accurate. Our FSCS Single Customer View Audit and Automation solution provides data insights and allows you to correctly identify the individuals and entities to be reported, including exclusion, effectiveness and completeness reports.
SCV Alliance
FSCS SCV Audit Platform
