SECN 9.5 Operational standards for data collection, aggregation, comparison, access and verification of completeness and consistency by securitisation repositories
Interpretation
- (1)
1Securitisation repositories must produce, on a daily basis, a single aggregate end-of-day report for all securitisations reported to them, excluding any reported securitisation that has been rejected in accordance with SECN 9.5.4R(7). That report must be based on the most recent reported information and must include at least the following information:
- (a)
the unique identifier assigned in accordance with SECN 11.12.1R;
- (b)
the International Securities Identification Number (ISIN) codes of the tranches, bonds or subordinated loans of the securitisation, where available;
- (c)
the sum of the current principal balances of all tranches, bonds or subordinated loans of the securitisation, in GBP, using the exchange rates published on the website of the Bank of England for the previous working day;
- (d)
the securitisation name;
- (e)
whether the securitisation is an ABCP transaction, an ABCP programme or a non-ABCP securitisation;
- (f)
whether the securitisation structure type is type ‘M’ for a Master Trust as reported in field SESS9 of SECN 11 Annex 14R or type ‘s’ for all other securitisations;
- (g)
whether the securitisation risk transfer method is ‘T’ for a true sale as reported in field IVSS11 of SECN 11 Annex 12R, ‘S’ for a synthetic securitisation as reported in field SESV11 of SECN 11 Annex 14R, or ‘ABCP’ for ABCP transactions or ABCP programmes;
- (h)
the name and legal entity identifiers (LEI) of the originator, sponsor and SSPE;
- (i)
the most recent interest payment date in ISO 8601 date format;
- (j)
the timestamp, in ISO 8601 date and time (UTC) format, to the nearest second, of the most recent data submission received by the securitisation repository or, where there are multiple data submissions referenced against the same data cut-off date, the timestamps, in ISO 8601 date and time (UTC) format, of the earliest and most recent data submissions with the same data cut-off date;
- (k)
the data cut-off date, in ISO 8601 date format, of the most recent data submission received by the securitisation repository;
- (l)
the number of data submissions received by the securitisation repository that are referenced against the same data cut-off date set out in (k);
- (m)
the data completeness score referred to in SECN 9.5.3R of the most recent data submission received by the securitisation repository;
- (n)
for non-ABCP securitisations, the country of establishment of the originator or original lender;
- (o)
for ABCP transactions or ABCP programmes, the country of establishment of the relevant sponsor of the ABCP programme;
- (p)
the country in which the majority of the underlying exposures is located, in terms of underlying exposure current principal balance; and
- (q)
the most prevalent type of the underlying exposures in the securitisation, in terms of current principal balance.
- (a)
- (2)
For the purposes of (n), where the securitisation’s underlying exposures are a combination of exposures from multiple originators or original lenders, the country of establishment of the originator or original lender must be the country of establishment of the originator or original lender that has the largest amount of exposures in terms of current principal balance in the securitisation.
- (3)
Securitisation repositories must make the end-of-day report available in extensible markup language (XML) format.
- (4)
Timestamps referred to in SECN 9.5.2R must not diverge by more than 1 second from the UTC issued and maintained by one of the timing centres listed in the latest Bureau International des Poids et Mesures (BIPM) Annual Report on Time Activities.
Scoring of completeness of data
1Securitisation repositories must calculate a data completeness score for each data submission by using the scoring matrix set out in Table 1 of SECN 9 Annex 3R and the following inputs:
Where:
denotes the total number of fields in a data submission containing the respective ‘No Data Option’ values that are reported in accordance with SECN 11.10.3R.
N denotes the total number of fields in the data submission where any ‘No Data Option’ values (ND1 to ND4) are permitted to be reported in accordance with SECN 11.10.3R.
For the purposes of calculating the data completeness score, fields completed using the format ‘ND4-YYYY-MM-DD’ must be understood as ‘ND4’.
Verification of completeness and consistency of information
- (1)
1Securitisation repositories must verify the completeness and consistency of information reported to them by verifying the following:
- (a)
the name of the reporting entity, as reported in field IVSS4 of SECN 11 Annex 12R or in field IVAS3 of SECN 11 Annex 13R; and
- (b)
whether the submission item code, as reported in Table 3 of SECN 11 Annex 1R, is correct.
- (a)
- (2)
With regard to the information referred to in SECN 6.2.1R(1), SECN 6.2.1R(5), SECN 6.2.1R(6) and SECN 6.2.1R(7), securitisation repositories must also verify the completeness and consistency of information by:
- (a)
verifying whether the information reported complies with the structure and format of the templates set out in SECN 12 Annex 2R to SECN 12 Annex 15R;
- (b)
comparing the information reported:
- (i)
across different fields for the same data cut-off date and the same underlying exposure, investor report, inside information or significant event information item;
- (ii)
across different underlying exposure, investor report, inside information or significant event information items for the same field and the same data cut-off date;
- (iii)
across the same underlying exposure, investor report, inside information or significant event information items for the same field and different data cut-off dates; and
- (iv)
across similar securitisations;
- (i)
- (c)
verifying whether the data cut-off date of the information reported and the timestamp of the submission comply with SECN 11.11; and
- (d)
verifying that the ‘No Data Options’ set out in SECN 11.10.3R are only used where permitted and do not prevent the data submission from being sufficiently representative of the underlying exposures in the securitisation.
For ABCP transactions and ABCP programmes, references in (2) to ‘underlying exposures’ must be construed as references to ‘underlying exposure types’.
- (a)
- (3)
Securitisation repositories must verify the completeness and consistency of the documentation made available to them under SECN 6.2.1R(2) by requesting from reporting entities a written confirmation of the following:
- (a)
that all items referred to in Table 3 of SECN 11 Annex 1R and required to be made available pursuant to SECN 6.2.1R(2) have been provided to the securitisation repository; and
- (b)
that the documentation is consistent with the actual arrangements and features of the securitisation.
- (a)
- (4)
Securitisation repositories must request the written confirmation referred to in (3) within the following timeframes:
- (a)
within 5 working days of the first issuance of securities under the securitisation or, for ABCP transactions or ABCP programmes, within 5 working days of the first issuance of securities under the relevant ABCP programme;
- (b)
every 12 months from the dates of the requests referred to in (a); and
- (c)
within 5 working days of a new document being made available pursuant to SECN 6.2.1R(2).
- (a)
- (5)
A securitisation repository that has not received a written confirmation within 14 days of the date of any request referred to in (3) must request the reporting entity to provide it with the written confirmation within 14 days.
- (6)
A securitisation repository must verify whether the STS notification referred to in SECN 6.2.1R(4), which has been made available to that securitisation repository, complies with the structure and format of the templates set out in SECN 2 Annex 4R, SECN 2 Annex 5R and SECN 2 Annex 6R.
- (7)
A securitisation repository must reject a submission of information that is incomplete or inconsistent pursuant to (1), (2) and (5), except for (2)(b)(iii) and (2)(b)(iv). The securitisation repository must assign submissions rejected pursuant to this paragraph to one of the rejection categories set out in Table 2 of SECN 9 Annex 3R.
- (8)
The securitisation repository must notify the entities referred to in SECN 9.3 without undue delay of the following:
- (a)
that the submitted information is incomplete or inconsistent pursuant to (2)(b)(iii) and (2)(b)(iv); and
- (b)
that the securitisation repository has not received the written confirmation referred to in (3).
- (a)
- (9)
Within 1 hour of the receipt of the information referred to in SECN 6, securitisation repositories must provide reporting entities with detailed feedback on the results of the verifications performed under (1), (2), (3) and (6), including any rejection category assigned pursuant to (7). That feedback must also include at least the following:
- (a)
the unique identifier of the securitisation assigned in accordance with SECN 11.12.1R;
- (b)
the item code(s) referred to in Table 3 of SECN 11 Annex 1R; and
- (c)
the submission timestamp, in ISO 8601 date and time (UTC) format, to the nearest second, of the information reported.
- (a)
- (10)
By 19.00.00 UTC each Monday, securitisation repositories must produce a report on all information rejected by it since 19.00.00 UTC on the previous Monday. That report must include at least the following items:
- (a)
the unique identifier of the securitisation assigned in accordance with SECN 11.12.1R;
- (b)
the securitisation name;
- (c)
the ISIN codes of the tranches or bonds or subordinated loans of the securitisation, where available;
- (d)
the name and LEI of the originator, sponsor and SSPE;
- (e)
the timestamp, in ISO 8601 date and time (UTC) format, to the nearest second, of the submitted information;
- (f)
the submission item code referred to in Table 3 of SECN 11 Annex 1R;
- (g)
the rejection category referred to in Table 2 of SECN 9 Annex 3R and the specific circumstances for assigning that rejection category; and
- (h)
any explanation(s) provided by the reporting entity before 17.00.00 UTC on the Monday of the report publication date as to why the reported information is incomplete or inconsistent, or as to why the written confirmation referred to in (3) has not been provided.
- (a)
Details of information to which access is to be granted
1The details of information referred to in SECN 9.3.1R are the following:
- (1)
all information received by the securitisation repository from reporting entities in accordance with SECN;
- (2)
the end-of-day report referred to in SECN 9.5.2R, the data completeness score referred to in SECN 9.5.3R and any information resulting from the verifications carried out pursuant to SECN 9.5.4R; and
- (3)
all formulae and calculation and aggregation methods used to produce the information referred to in (1) and (2).
Terms and conditions for access to details of information
- (1)
1Access to the information referred to in SECN 9.5.5R must be granted on request. The request for access must include the following information:
- (a)
the name of the requesting entity;
- (b)
the contact person at the requesting entity;
- (c)
the type of requesting entity, as referred to in SECN 9.3, that requests access;
- (d)
the names of the persons at the requesting entity who will have access to the requested information;
- (e)
credentials for secure SSH File Transfer Protocol connection as required by SECN 9.5.7R(2);
- (f)
whether the request is an ad hoc or predefined periodic request;
- (g)
the identification of the information requested based on any combination of the criteria in (4); and
- (h)
any other technical information relevant to the requesting entity’s access.
- (a)
- (2)
For the purposes of (1), securitisation repositories must:
- (a)
designate a person or persons responsible for liaising with the entities referred to in SECN 9.3.1R;
- (b)
publish on their website the terms and conditions for accessing the information and the instructions for submitting a request for accessing that information;
- (c)
provide access only to the information specified in the request for access; and
- (d)
as soon as possible, but no later than 30 days following a request to set up access to that information, establish the technical arrangements necessary to enable the entities referred to in SECN 9.3.1R to submit requests to access that information.
- (a)
- (3)
Access to the information referred to in SECN 9.5.5R must be granted within the following timeframes:
- (a)
no later than 19.00.00 UTC on the day to which the report relates for an ad hoc or predefined periodic request for an end-of-day report as referred to in SECN 9.5.2R;
- (b)
no later than 12.00.00 UTC on the first day following the day of receipt of the request for access where the information concerns a securitisation that has either not yet been priced or has not yet matured or has matured less than 1 year before the date on which the request was submitted;
- (c)
no later than 3 working days following the day of receipt of the request for access where the information concerns a securitisation that has matured more than 1 year before the date on which the request was submitted; and
- (d)
no later than 3 working days following the day of receipt of the request for access where the information concerns several securitisations falling under both (b) and (c).
- (a)
- (4)
- (a)
securitisation type:
- (i)
non-ABCP securitisation; or
- (ii)
- (i)
- (b)
securitisation structure type: either
- (i)
‘M’ for Master Trust as reported in field SESS9 of SECN 11 Annex 14R; or
- (ii)
‘S’ for all other securitisations;
- (i)
- (c)
securitisation risk transfer method: either type ‘
- (i)
‘T’ for true sale as reported in field IVSS11 in SECN 11 Annex 12R;
- (ii)
‘S’ for synthetic as reported in field SESV11 in SECN 11 Annex 14R; or
- (iii)
‘ABCP’ for ABCP transactions or ABCP programmes;
- (i)
- (d)
securitisation item code;
- (e)
securitisation underlying exposure type;
- (f)
securitisation underlying exposure section;
- (g)
securitisation investor report template section;
- (h)
securitisation inside information or significant event information template section;
- (i)
identifier:
- (i)
unique identifier;
- (ii)
transaction identifier;
- (iii)
ISIN;
- (iv)
new or original tranche/bond identifier;
- (v)
new or original underlying exposure identifier;
- (vi)
new or original obligor identifier;
- (vii)
originator LEI;
- (viii)
sponsor LEI;
- (ix)
SSPE LEI;
- (x)
original lender LEI; or
- (xi)
collateralised loan obligation (CLO) manager LEI;
- (i)
- (j)
geography:
- (i)
geographic region; or
- (ii)
governing law;
- (i)
- (k)
date and time:
- (l)
currency:
- (i)
tranche/bond currency; or
- (ii)
underlying exposure currency denomination.
- (i)
- (a)
- (5)
Securitisation repositories must make the following information available using XML format:
- (a)
the information referred to in SECN 6.2.1R(1) and SECN 6.2.1(4) to SECN 6.2.1(7); and
- (b)
the information produced by securitisation repositories in accordance with SECN 9.5.2R and SECN 9.5.4R, with the exception of written confirmations received under SECN 9.5.4R(3).
- (a)
Standards for data collection and access
- (1)
1Securitisation repositories must use electronic signature and data encryption protocols to receive data from reporting entities or other securitisation repositories and to transfer data to the entities referred to in SECN 9.3.
- (2)
For the purposes of (1), securitisation repositories must establish and maintain a secure machine-to-machine interface and make that interface available to the reporting entities and the entities referred to in SECN 9.3. That interface must make use of the SSH File Transfer Protocol.
- (3)
Securitisation repositories must use standardised XML messages to communicate through the interface referred to in (2) and make the information set out in SECN 9.5.6R(5) available to the entities referred to in SECN 9.3.
Recordkeeping
- (1)
1Securitisation repositories must record the following:
- (a)
verifications pursuant to SECN 9, and any other validation carried out by the securitisation repository;
- (b)
the written confirmations received by the securitisation repository referred to in SECN 9.5.4R(3);
- (c)
the results provided by the securitisation repository to the reporting entity pursuant to SECN 9.5.4R(9);
- (d)
any explanation provided by the reporting entity as to why the submitted information is incomplete or inconsistent, or as to why there is no written confirmation as referred to in SECN 9.5.4R(10)(h);
- (e)
in a reporting log, the details of any corrections or cancellations submitted by the reporting entity; and
- (f)
any other information produced or submitted pursuant to SECN.
- (a)
- (2)
Each record must be retained for 10 years following the termination of the securitisation to which that record relates.
- (3)
The reporting log referred to in (1)(e) must include the unique identifier of the securitisation, the item code, the timestamp of the affected submission, the timestamp of the changes and a clear description of the changes to the submitted information, including the previous and new contents of that information.