8. Account

8.1 What is the ‘compensatable’ amount field for?

  • The compensatable amount field will be used by FSCS to determine how much compensation will be paid to the customer. Deposit takers should note that:

1. It should never be more than the compensation limit; and

2. It should not include the limit itself (i.e. currently £85,000), unless of course the customer has an aggregate balance equal to or greater than the existing limit (when compensation paid has to be capped at the limit).

8.2 How should the ‘account status’ field be populated where an account has more than one ‘issue’ that necessitates more than one key/code?

  • FSCS intend to use the account status code field to help determine the appropriate treatment for SCV records and accounts. In order to do this, it is essential that all deposit takers provide FSCS with the keys and codes that are applied to the account status field.
  • Where deposit takers have multiple status codes that need to be applied to an account (e.g. Fraud, suspect money laundering and Gone Away), FSCS would prefer to receive the mapping information for the combined codes as a distinct code in the keys/codes table (that will be submitted as part of the Implementation Report).
  • For example, where an account has a ‘Fraud’, ‘Money Laundering’ and ‘Gone Away’ code, we would expect to see a unique code that represents these combined codes. Some indicative examples are given in Row 4-7 below that might represent a combined code scenario.
  Account status key or code(s) Description(s) Fit for straight through payout?
1 FRAUD Fraud risk N
2 LAUND Money Laundering N
3 GONEA Gone Away N
4 FRLAGO Fraud risk, Money Laundering, Gone Away N
5 FRAUD / LAUND / GONEA Fraud risk, Money Laundering, Gone Away N
6 FLG Fraud risk, Money Laundering, Gone Away N
7 GONEA / FRAUD / LAUND Gone Away, Fraud risk, Money Laundering N

 

  • Deposit takers should note that the code listed in the ‘Account status key or code (s)’ column must be an exact match to the code that appears in the account status fields within the Account Status field in the SCV file. Please note, where deposit takers are specifying a combined code (e.g. FRAUD/LAUND/GONEA), each combination must be specified. For the avoidance of doubt:

1. FRAUD/LAUND/GONEA, is not the same as,

2. GONEA/FRAUD/LAUND.

Both codes would need to appear in the keys and codes table if both codes appeared in the SCV file.

8.3 What is the ‘account status code’ field for?

  • FSCS intend to use the account status code field to help determine the appropriate treatment for SCV records and accounts.
  • We recognise that different deposit takers will have a variety of ‘codes or keys’ that are applied to accounts for a range of reasons.
  • COMP 17.3.7 requires deposit takers to provide an explanation of the different keys and codes (applied at an account level) to the account status field in the SCV file.
  • FSCS intend to use the ‘keys and codes’ information provided in the ‘account status field’ to determine the appropriate treatment for each of the SCV records and account types. For example, while dormant accounts under the Dormant Bank and Building Societies Act 2008 should be excluded from the SCV, ‘gone aways’ (and other accounts that are ‘not fit for straight through to payout’), should be flagged with the relevant key or code that allows FSCS to identify and prevent automated payout. Explanatory details of the key or codes used by each deposit taker should be contained in the Implementation Report submitted to the FSA. For further information on Pre Implementation, Implementation and SCV Reports see Section 7.
  • Deposit takers will note that account status code allows flagging at account level, not SCV level. As such, where one account is flagged as (say) a ‘gone away’ and the remaining accounts (for the same customer) are fit for straight through to payout, FSCS will extract the SCV record from the straight through payout file. The whole SCV record will then be subject to a separate FSCS process.
  • For the avoidance of doubt, deposit takers will not be required to adhere to a set of pre defined keys or codes and should include their own existing, and any new, codes.

See Question 1.1 and 8.7

8.4 How does the FSCS expect the Account Holder Indicator to be used? For example, a joint account where one account holder is deceased, an executor has been appointed and someone holds a Power of Attorney over the account. Will the account holder indicator be used to enable the FSCS to count the number of beneficial owners for the account or to infer some kind of relationship to the account?

  • The FSCS intends to use the ‘Account Holder’ indicator to identify that the balance has been split correctly where there are multiple account holders. This information will be primarily used to support FSCS customer service in a default scenario.

8.5 What exactly should the Single Customer View file contain?

  • The SCV table (table 1) sets out what is required in the SCV file itself under the FSA rules (the Field identifier and Field descriptor columns).
  • While the first two columns are required by the rules (in COMP 17.2.3 (3)), the remaining columns set out how deposit takers can assist the FSCS in providing data in a format that is compliant with and adaptable to our systems (the Description of FSCS preference, Data Type, Length and Example/Convention columns).
  • For the sake of clarity, where an eligible depositor has more than one account, the ‘Details of Account(s)’ table should be replicated for each account.

8.6 The SCV table requires National Insurance (NI) numbers to be provided where held by the firm. Do deposit takers need to start collecting NI numbers?

  • While the use of a relatively wide spread unique identifier such as NI numbers will offer some advantages regarding record matching, it is only required within the SCV where held by the deposit taker. For example, for accounts such as ISAs where HMRC already require the collection of NI numbers.

8.7 What does ‘fit for straight through payout’ actually mean?

  • An account that is deemed ‘fit for straight through payout’ should not require any additional checks on the completeness or accuracy of the SCV file. Therefore, as a general rule, if a firm is happy to pay a customer the balance of their account without any additional checks or data gathering being required, this would be considered an account ‘fit for straight through to payout’.
  • While the FSCS will perform some initial checks on the completeness and accuracy of an SCV file in a default/payout situation, in order to achieve speedy payout, those accounts that are ‘fit for straight through to payout’ will proceed directly to payout without manual intervention. (For the avoidance of doubt, all payments will be subject to sanctions screening)

8.8 How should deposit takers deal with the return element of a structured deposit, where the return calculation is unknown?

  • Where the return element of a structured deposit cannot be calculated until a particular point in time, for example, a structured deposit is linked to an index at a future date, such that the rate or calculation of the return is not known until that future date, deposit takers should include the principal in the SCV file and apply to the FSA for a waiver allowing them to exclude the return element. See also (the other question on structured deposits, which will give links to the waiver process etc).

8.9 What is the ‘account status code’ field for?

  • FSCS intend to use the account status code field to help determine the appropriate treatment for SCV records and accounts.
  • We recognise that different deposit takers will have a variety of ‘codes or keys’ that are applied to accounts for a range of reasons.
  • COMP 17.3.7 requires deposit takers to provide an explanation of the different keys and codes (applied at an account level) to the account status field in the SCV file.
  • FSCS intend to use the ‘keys and codes’ information provided in the ‘account status field’ to determine the appropriate treatment for each of the SCV records and account types. For example, while dormant accounts under the Dormant Bank and Building Societies Act 2008 should be excluded from the SCV, ‘gone aways’ (and other accounts that are ‘not fit for straight through to payout’), should be flagged with the relevant key or code that allows FSCS to identify and prevent automated payout. Explanatory details of the key or codes used by each deposit taker should be contained in the implementation reportsubmitted to the FSA. For further information on Pre Implementation, Implementation and SCV Reports see Section 7.
  • Deposit takers will note that account status code allows flagging at account level, not SCV level. As such, where one account is flagged as (say) a ‘gone away’ and the remaining accounts (for the same customer) are fit for straight through to payout, FSCS will extract the SCV record from the straight through payout file. The whole SCV record will then be subject to a separate FSCS process.
  • For the avoidance of doubt, deposit takers will not be required to adhere to a set of pre defined keys or codes and should include their own existing, and any new, codes.

See Question 1.1 and 8.7

8.10 What is the required format for the Single Customer View Record Number (SCVRN)?

  • Whilst the rules are silent on the format of the SCVRN, FSCS would like to remind deposit takers that it is our strong preference that each SCVRN start with the relevant FSA Firm Registration Number (FRN).

8.11 What about the data structure/field order of the SCV records?

  • While the COMP rules do not provide any details on the data structure of the SCV file, FSCS would prefer to receive SCV files in a multi file format.
  • The FSCS preferred composition would be one file containing tables A, B and D and a second file containing table C as detailed in Table 1, Section 3 of this document. Firms who elect to use the FSCS’ preferred composition may wish to note the following FSCS recommendations:
  1. To avoid duplicating customer details in each record, the SCV records can be split into multiple files as per the tables A- D defined in Table 1, Section 3 of the document
  2. All files should contain a header and footer (preferably in the preferred format set out in response to (Question 2.1 and 8.13) in a consistent format;
  3. Each unique SCV ID should appear once in tables A, B and D and at least once in table C. The count of unique SCV ID must be the same across all files;
  4. Each table can be sent as one separate file, or any combination of tables A,B and D, however table C should be sent as a separate file;
  5. The set of files can be split by fit for straight through payout/not fit for straight through payout or can be combined but must be consistent across the set of files (as described in Annex C of this document);
  6. The address format must be consistently applied on all files (either FORMAT A/PAF or FORMAT B/Multi line);
  7. Files should only contain the fields specified within COMP; and
  8. Each file must contain a single record layout and all fields must be in the same position on every record.

An example of the preferred multi file layout can be found on the FSCS website.

  • Should deposit takers choose not to provide the content of the SCV files in the above formats, the FSCS invites these deposit takers to provide details of their proposed data structure, in the Implementation Report.
  • For further questions about the submission of the pre implementation report, implementation report, SCV report and SCV sample data, please refer to Section 7.

8.12 What information should be included in the account title field?

  • See the examples given in Table 1.

8.13 Is there a preferred footer format?

  • Yes. See below for the preferred footer format
Field identifier Field description Max Data Length in Bytes Layout Contend Type Notes
  Character to indicate footer record 20 Numberic Numeric 9999999999999999999

8.14 What check totals/header information should be used for file transmission to FSCS?

  • Check totals should be provided in the preferred header format below:

Check total header information

Field identifier Field descriptor Max data length in bytes Layout Content Type Notes
Spaces Spaces 14   Spaces  
Header HEADER 6 Alpha-
numeric
Character Header
FRN FRM of the SCV file 6 numeric Numeric 000000 = FRN number for the file
File Generation
Date and Time
File
Generation
Date and Time
14 YYYYMMDD
HHMMSS
Date YYYY = Year, MM = Month, DD = day HH = hours, MM = minutes, SS = Seconds

YYYYMMDDHHMMSS
Total Unique Customer Count Count of unique CSV IDs 9 numeric Unsigned numeric Total number of unique SCV IDs

#########
Total Record Count Count of all records excluding the header and footer 9 numeric Unsigned numeric Total number of unique SCV IDs

#########
Filename Name of SCV file 50 Alpha-
numeric
Character  

8.15 Are there any characters (e.g. @ or !) that are prohibited from use by COMP?

  • No. COMP does not restrict the use of characters such as @ or !.
  • However, use of the characters (see Table 2 below) within any fields within your SCV file will result in the SCV ID being extracted for manual inspection by FSCS.

Table 2: Single Customer View – Additional check characters

Character
!
$
%
*
+
;
<
=
>
?
@
^
_
|
~
DEL (Character)

 

8.16 How do deposit takers treat offset mortgages where there is a negative balance?

  • Set off is disapplied for FSCS payout purposes so that if a depositor also owes a desposit taker money, the debt is no longer set off against the deposit in calculating the amount of the protected deposit. This has implications for offset mortgages.
  • If the deposit account is separately identified from the mortgage balance, it should be separated and compensation calculated on a gross basis. However, if the deposit account is combined with the mortgage account, the FSCS would have to treat it as an overdraft and no compensation would be payable.
  • PS09/11 explained that the two most common types of offset mortgage structures had been identified as:

1. Type 1: a savings/current account which is usually separately identified from the mortgage balance. The balance in the account is offset against the mortgage and interest is calculated on the amount of the mortgage debt less the amount on deposit;

2. Type 2: a current account is combined with a mortgage account and operated as one large overdraft (with a credit limit).

  • In the first type, deposits are normally separately identified from the mortgage balance, therefore the FSA consider that it should be relatively easy to separate the two elements and calculate compensation on a gross basis.
  • In the case of the second type, the FSA consider that the nature of the product meant it might not be possible to separate the deposit element from the mortgage element; the FSCS would simply have to treat the single balance as a debt to the bank (i.e. as an overdraft).

8.17 How should deposits held as security be treated?

  • The Glossary definition of a deposit, which reflects the Regulated Activities Order (RAO) definition, excludes a deposit paid on terms... which are referable to the giving of security if… it is paid by way of security for the performance of a contract or by way of security in respect of loss which may result from the non-performance of a contract.
  • Whether a deposit falls within the RAO definition will turn on the particular facts. Some examples may explain the position.

Example 1

Say that Bank A lends money to Son B. Mother C has a deposit with Bank A and Mother C pledges that deposit to Bank A as security for Son B’s debt to Bank A. The key is that Bank A is both the deposit-taker and the person to whom security is given.

In this case FSA’s view is that in principle the deposit falls outside the RAO definition of a deposit and so will not be covered by the FSCS and will therefore be outside the SCV. It falls outside the definition because the deposit is paid by way of security for the performance of a contract. This covered by the exclusion in articles 5(2) and (3) of the RAO.

However, what if Mother C’s deposit was originally just an ordinary savings account not paid by way of security? Does the deposit stop being a deposit just because later it is pledged to the bank without a new sum being paid into the account? This is arguable, but the FSA tends to the view that in this scenario the deposit stays as an RAO deposit. This is because the exclusion applies to monies that are paid as security; one must look at the purpose at the time the deposit is originally made.

Example 2

There is a related issue. What if Mother C pledges her current account? The account is being used for two purposes - as a current account and as security. Is this excluded? FSA considers that again this is arguable but that the preferable view is that it remains an RAO deposit.

Example 3 Say that A grants B a loan. Neither is a bank. B has an account with Bank C and B grants security to A over that account in order to secure B’s loan obligation to A. Assuming the deposit meets the other conditions in COMP, B’s deposit will be protected.

  • The availability of FSCS cover will depend on the particular scenario. It is for firms to decide whether an account needs to be included in the SCV for payment of compensation by FSCS.

8.18 How should firms flag customers who have specific needs such as visual impairments?

  • Firms should flag customers who have specific requirements (e.g. Braille or large print requested), with a relevant key or code in the account status code field.
  • Where deposit takers flag customers with specific requirements (e.g. Braille or large print requested), FSCS would ask that the appropriate key or code is applied indicating that:

1. The specific requirement of that particular customer; and

2. That the relevant keys and codes in the Implementation Report Template is marked as NOT being fit for straight through payout.

8.20 A number of overseas customers live in a country that does not have a postal system and the use of PO Boxes is common place.  If this is the case can this information be placed in Table B of the report?

  • If a PO Box number is entered into Table B in the SCV table, and a cheque is used to make payment, the FSCS would send any payment to the PO Box number. The deposit taker must be satisfied that this is an appropriate address for payment.

8.21 How should joint account holders be treated in relation to the compensation ‘limit check’?

  • Where there are two account holders the funds should be split 50:50 unless the deposit taker has evidence that the holders’ respective shares are not 50:50 in which case the actual split must be used. Compensation balances are not portable from one individual to another.

8.22 How should deposit takers deal with in-flight transactions?

  • Within the 72 hour period, and prior to generating and sending the SCV file to FSCS, we would expect firms to take a rigorous and comprehensive approach to the identification and application of in-flight transactions (initiated prior to default) to those accounts within the SCV file.
  • For the avoidance of doubt, we would expect firms to apply all transactions that are known by the firm AND that were irrevocable prior to the point of default. The FSA recognises that SCV file production methods will differ from firm to firm. As such, where certain payment types are not likely to be applied to the balances, a summary of these omissions should be included in the ‘Issues’ section of the Pre Implementation Report and / or the ‘Any other relevant factors‘ sections of the Implementation Report.
  • The FSA recognises that deposit takers may encounter challenges in applying in-flight transactions in relation to their sample file, during the verification phase.
  • The FSA expect firms to take a rigorous and comprehensive approach to the identification and application of in-flight transactions during verification. Firms should summarise any omissions or issues encountered in the 'Any other relevant factors' section of the Implementation Report.