New Changes in 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 email@example.com 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.
|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:
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
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.
Get to Know more about FSCS SCV Regulatory Compliance
Get to Know more about FSCS SCV Regulatory Compliance
- FSCS SCV Enterprise Solution Suite | All-in-one
- Customer Pain Points & Solutions – Fully Resolved Necessity of FSCS SCV Regulatory Reporting Tool for Banks
- Why banks in UK/Europe need FSCS Single Customer view Automation/Audit?
- Stay FSCS compliant always with our SCV Alliance – FSCS SCV Audit Platform
- Generate your FSCS SCV report in just 3 steps
- Regulatory Compliance for Banks
- Standardisation of Data for FSCS Compliance – MG’s Data Governance Framework model