REGISTRATION DATA INTERFACE SPECIFICATION

Transcription

1 REGISTRATION DATA INTERFACE SPECIFICATION DEFINITIONS Data Transfer Catalogue DCC Status DCC Status File Electricity Registration Data Provider Gas Registration Data Provider Hot Standby Router Protocol Network Address Translation Registration Data File Registration Data Update File Registration Data Refresh File Means the Data Transfer Catalogue as published on the Master Registration Agreement Service Company website at providing logical definition of the data flows used to communicate information between electricity industry participants Means the status of each Electricity Metering Point or Gas Supply Meter Point with respect to whether a Smart Metering System is Enrolled or Withdrawn Means the file produced by DCC and transferred to each Network Party detailing the DCC Status of each Electricity Metering Point or Gas Supply Meter Point registered to that Network Party. Means a Registration Data Provider which sends and receives Electricity Registration Data. Means a Registration Data Provider which sends and receives Gas Registration Data. Means the published protocol used to provide redundancy and thus establish a fault-tolerant default gateway, in this case the Registration Data Interface Means the internet standard method of modifying Internet Protocol (IP) network address information using a traffic routing device, for the purpose of remapping one IP address into another Means the file or files produced by each Network Party and transferred to the DCC detailing the Registration Data pursuant to section E1. Means the Registration Data File containing periodic updates to Registration Data. Means the Registration Data File containing updates to Registration Data for a partial or full list of Metering Points or Supply Metering Points. 02.Registration_Data_Interface_Specification_consultation_version 1

2 Response File Supported Version 1. INTRODUCTION Means a file produced whilst processing a data file containing either successful acknowledgement records or validation error records recorded in processing. Means the latest version of the Data Transfer Catalogue data flow that the DCC supports for use with the Registration Data Interface as listed and as updated from time to time on the DCC web site. Document Purpose Pursuant to [E2.8], this document is the Electricity Registration Data Interface Specification and Gas Registration Data Interface Specification. 2. REGISTRATION DATA INTERFACE Establishment of the REGIS logical connection 1.1 The DCC shall make the Registration Data Interface available on an Internet Protocol version 4 address range. 1.2 Each Network Party shall use Network Address Translation to remap internal Internet Protocol addresses to the published DCC provided Internet Protocol addresses at the Network Party s firewall prior to accessing the Registration Data Interface. 1.3 Each Network Party shall use Network Address Translation to remap incoming DCC traffic Internet Protocol addresses from the published Internet Protocol addresses at the Network Party s firewall to the reserved Internet Protocol addresses within their subnet. Secure Shell File Transfer Protocol transfers 1.4 The Registration Data Interface shall utilise the Secure Shell File Transfer Protocol between the RDP Systems and the DCC Systems. 1.5 The DCC and each Network Party shall implement the Secure Shell File Transfer Protocol interface in a standard format conforming to the following internet standards as defined in the referenced Request for Comments (RFC) as published by the Internet Engineering Task Force (IETF) and the Internet Society at 02.Registration_Data_Interface_Specification_consultation_version 2

3 editor.org/rfc.html (b) (c) (d) (e) (f) Secure Shell (SSH) protocol, in accordance with RFC 4251, RFC 4252 and RFC 4253 In accordance with RFC 4251, RFC 4252, RFC 4253 and RFC 959 (File Transfer Protocol) for the purposes of error handling The Transport Layer shall use encrypted communications using the AES (Advanced Encryption Standard), FIPS-197, in CBC mode (AES-128- CBC) The Transport Layer shall use Message Authentication Code (MAC) communications using the Hash-based Message Authentication Code (HMAC) construct for calculating the MAC in accordance with RFC 2104, combined with the hash function SHA1 (HMAC-SHA1) The Transport Layer shall use Raw DSS (Digital Signature Standard) Keys in SSH-DSS format Access to the Secure Shell File Transfer Protocol interface shall be authenticated by mutual Public Key Authentication in line with RFC The DCC and each Network Party shall use DCCKI certificates for the purposes of signing and authenticating files, as defined in 1.10, 1.11 and The DCC and each Network Party shall follow the relevant steps in the process below when sending or receiving data files required under Section E2.1, Section E2.2 and Section E2.4. The sending and receiving party shall: structure data files it provides under E2.1, Section E2.2 and Section E2.4 in accordance with the structures defined in 1.22, 1.23, 1.24, 1.30, 1.32 and 1.33 of this document and shall include a unique sequential file sequence number in accordance with 1.17and 1.26 (b) sign the file in accordance with 1.10 and 1.11 (c) connect to the recipient s Secure Shell File Transfer Protocol server using 02.Registration_Data_Interface_Specification_consultation_version 3

4 the DCC Gateway Connection. (d) (e) (f) (g) (h) (i) (j) initiate the transfer of the file to the relevant delivery directory on the recipient s Secure Shell File Transfer Protocol server utilising Secure Shell File Transfer Protocol push mechanisms for all file exchanges authenticate the source of the file through verifying that the file has been digitally signed in accordance with 1.12, validating the file sequence using the unique sequence number as defined in 1.17and 1.26 and validating the file structure against the structure as defined in 1.22, 1.23, 1.24, 1.30, 1.32 and 1.33 of this document where the recipient is unable to authenticate the file pursuant to 1.7(e) the recipient shall raise an Incident as defined in the Registration Data Incident Management Policy where the Network Party is unable to validate the file structure pursuant to 1.7(e) the Network Party shall generate a Response File as defined in 1.23(d) or 1.32(b) within this document. The Response File will then be signed and sent to DCC using the steps outlined immediately above in 1.7 to (d) and on receipt of the Response File containing validation errors the DCC shall raise an Incident as defined in the Registration Data Incident Management Policy where the DCC is unable to validate the file structure pursuant to 1.7(e) the DCC shall raise an Incident as defined in the Registration Data Incident Management Policy where the Network Party or DCC is able to successfully authenticate and validate the file pursuant to 1.7(e), the recipient Network Party or DCC shall process each record within the file and perform record level validation where the Network Party is unable to successfully validate and process each record within the file pursuant to 1.7(i) the Network Party shall generate a Response File as defined in 1.23(d) and 1.32(b) within this document. The Response File will then be signed and sent to DCC using the steps outlined immediately above in 1.7 to (d) and on receipt of the Response File 02.Registration_Data_Interface_Specification_consultation_version 4

5 containing validation errors the DCC shall raise an Incident as defined in the Registration Data Incident Management Policy (k) where the DCC is unable to successfully validate and process each record within the file pursuant to 1.7(i) the DCC shall raise an Incident as defined in the Registration Data Incident Management Policy Security Requirements 1.8 The DCC shall allocate to each Network Party a separate directory within the Secure Shell File Transfer Protocol server and permit access only to write files and obtain directory listings within their assigned directory, and not to read, modify and delete files. 1.9 Prior to sending a file via the Registration Data Interface, the DCC and each Network Party shall establish a Transport Layer Security session. The DCC and each Network Party shall implement Transport Layer Security in a standard format conforming to: 1. The Transport Layer shall use Transport Layer Security version 1.2 as specified in Request for Comments (RFC) 5246 as published by the Internet Engineering Task Force (IETF) and the Internet Society at 2. The Transport Layer shall utilise the cipher suite TLS_RSA_WITH_AES_128_GCM_SHA256 as catalogued and further defined by the Internet Assigned Numbers Authority within the Cipher Suite Registry at 3. The Transport Layer Security connection shall be established between a non-dcc PEP and the DCC's PEP 4. Each Network Party shall ensure that DCCKI Certificates are used to establish the Transport Layer Security connection 02.Registration_Data_Interface_Specification_consultation_version 5

6 1.10 The DCC and each Network Party shall sign each file sent via the Registration Data Interface with the appropriate DCCKI digital signing key in accordance with FIPS digital signature standard using SHA-256 hashing algorithm and encrypting the derived hash using a RSA Digital Signing Algorithm of 2048-bit modulus in accordance with PKCS # The DCC and each Network Party shall apply to the entire file the SHA-256 hashing algorithm generated in accordance with 1.10 of this document, including the header and trailer. The DCC and the Network Party shall convert the resulting 2048 bits Octet digital signature to Base64 and append within the file itself to the trailer with a preceding, separator The DCC and each Network Party shall use the organisation identifier within the header of the file to retrieve the appropriate public key. The DCC and each Network Party shall perform a SHA-256 hashing algorithm on the file excluding the signature and verify the signature in accordance with FIPS Interface Error Handling 1.13 Where an error is encountered, the DCC and each Network Party shall raise an Incident in accordance with the Registration Data Incident Management Policy. The following errors can occur when using the Registration Data Interface: Connection failure Any connection failure or file transfer failure that occurs when sending files via the Registration Data Interface; (b) Transport authentication failure Failure to establish a TLS session in accordance with 1.9 when trying to send a file via the Registration Data Interface; (c) Digital signature verification failure This occurs when the digital signature on a Registration Data file cannot be verified in accordance with Registration_Data_Interface_Specification_consultation_version 6

7 (d) File processing failure This occurs when a Registration Data File cannot be validated in accordance with Registration Data file formats. (e) SFTP access failure This occurs when the DCC and the Network Party cannot establish an SFTP connection in accordance with INTERFACE FILES General Obligations 1.14 The DCC shall maintain a separate unique reference number for each Network Party, common across all files it sends through the Registration Data Interface to that Network Party. Each Network Party shall check this common sequence number in order to detect duplicate, missing or out-of sequence files as defined in the process step 1.7(e) and may if necessary raise an Incident as defined in the Registration Data Incident Management Policy Each Network Party and the DCC shall not use file compression on files transferred through the Registration Data Interface The DCC shall maintain a minimum of 24 months of the required historic Registration Data within DCC Systems. Electricity Registration Data File Structure and Data Formats 1.17 Each Electricity Network Party shall maintain a unique reference number for files, maintained across all files it sends through the Registration Data Interface. Each file shall include this unique reference number within the file header, taken from a monotonically increasing number generator. The DCC shall check this unique reference number in order to detect duplicate, missing or out-of sequence files as defined in the process step 1.7(e). 02.Registration_Data_Interface_Specification_consultation_version 7

8 1.18 Each Electricity Network Party shall provide Registration Data Update Files to the schedule as outlined in the DCC Gateway Connection & Codes of Connection 3.4 and 3.5 irrespective of whether there are Registration Data updates to convey. Where there are no Registration Data updates, each Electricity Network Party shall provide a Registration Data Update File containing the standard header, trailer and unique sequence number record and no further data records Each Electricity Network Party shall provide refresh Registration Data Files where the DCC requests in accordance with Section [E2.7] and may provide up to one unsolicited partial refresh Registration Data Refresh File each day Each Electricity Network Party shall employ a file naming convention that ensures that each of the files it sends through the Registration Data Interface has a unique name For electricity Registration Data Files, DCC shall employ a file naming convention that ensures that each file sent through the Registration Data Interface has a unique name, using the following items separated by the underscore character, giving the overall naming layout: DCCO_D0123_ where: (b) (c) DCCO is the organisation identifier (As defined by the MRA) D0123 is the flow reference (As defined by the MRA) is the unique reference number (unique within DCC files for each Electricity Network Party) 02.Registration_Data_Interface_Specification_consultation_version 8

9 1.22 Each Electricity Network Party shall ensure that all files contain header and trailer records that conform to the formats as detailed below: File Header Data Item Format Comment File Identifier CHAR(10) File identifier - unique within Market Participant (i.e. the file unique sequence number) Data flow and Version Number From Market Participant Role Code CHAR(8) CHAR(1) Dxxxxnnn Consists of 5 char data flow reference followed by 3 character flow version number - where n has a range of 0-9 e.g. 001, e.g. Registration systems have value P From Market Participant Id CHAR(4) e.g. DCC has value DCCO To Market Participant Role Code CHAR(1) e.g. DCC has value Z To Market Participant Id CHAR(4) e.g. DCC has value DCCO File creation timestamp CHAR(14) DATETIME (GMT) DCC is using UTC Sending Application Id CHAR (5) Application identifier. For possible future use Receiving Application Id CHAR (5) Application identifier. For possible future use Broadcast CHAR (1) For possible future use. Test data flag CHAR (4) Indicates whether or not this file contains test data. (b) File Trailer Data Item Format Comment File identifier CHAR(10) File identifier - unique within Market Participant Total Group Count INT (10) Total number of Groups in file excluding header/trailer Checksum INT (10) Checksum Flow count INT (8) Number of flow instances excluding file header/trailer File completion timestamp CHAR(14) DATETIME (GMT) DCC is using UTC 02.Registration_Data_Interface_Specification_consultation_version 9

10 1.23 Each Electricity Network Party shall provide the following files, which are to conform to the latest Supported Version of the specified data flow structures as defined in the Data Transfer Catalogue. Initial upload and full Registration Data Refresh File To provide the DCC with an initial population of Registration Data and any subsequent full Registration Data refresh, each Electricity Network Party shall send a Registration Data Refresh File as specified in the Data Transfer Catalogue D0353 data flow. (b) Daily Registration Data Update File To notify the DCC of any changes to relevant Registration Data, each Electricity Network Party shall send a Registration Data Update File as specified in the Data Transfer Catalogue D0348 data flow. (c) Registration Data Refresh File - Partial refresh To provide the DCC with a partial refresh of Registration Data, each Electricity Network Party shall send a Registration Data Refresh File as specified in the Data Transfer Catalogue D0349 data flow. (d) Response File - DCC Status update rejections To notify the DCC of any data records rejected during processing of a DCC Status File due to validation errors, each Electricity Network Party shall send a Response File as specified in the Data Transfer Catalogue D0351 data flow. (e) Response File - DCC Status update acknowledgement To notify the DCC of successful processing of the Status Update file, each Electricity Network Party shall send a Response File as specified in the Data Transfer Catalogue D0172 data flow. 02.Registration_Data_Interface_Specification_consultation_version 10

11 1.24 The DCC shall provide the following files to each Electricity Network Party conforming to the data flow structures as defined in the Data Transfer Catalogue: DCC Status File To notify Electricity Network Parties of DCC Status updates, the DCC shall send a DCC Status File as specified in the Data Transfer Catalogue D0350 data flow Each Electricity Network Party shall provide Registration Data Refresh Files utilising the Secure File Transfer Protocol connection or via an alternative means as agreed between the DCC and the Electricity Network Party. Gas Registration Data File Structure and Data Formats 1.26 Each Gas Network Party shall maintain a unique reference number for files, maintained across all files it sends through the Registration Data Interface. Each file (with the exception of the multiple file confirmation file as defined in 1.32(c)) shall include this unique reference number within the file header, taken from a monotonically increasing number generator. The DCC shall check this unique reference number in order to detect duplicate, missing or out-of sequence files as defined in the process step 1.7(e) The DCC shall use and each Gas Network Party shall use industry standard comma separated file format for exchanging files. Files sent shall: (b) (c) (d) (e) (f) Include fields which are comma-separated Only use ASCII characters Not exceed the field lengths shown below at 1.32 and exclude any opening and closing double quotation marks or comma separators Not pad values that are less than the maximum field length Enclose text fields with opening and closing double quotation marks, but use no quotation marks in date and numeric fields Ensure blank fields contain no characters other than opening and closing 02.Registration_Data_Interface_Specification_consultation_version 11

12 double quotation marks for text fields 1.28 Each Gas Network Party shall employ the file naming convention described below in to (e), ensuring that each file sent through the DCC Gateway has a unique name. Within the names shown in to (e): PN indicates that the files are production (will be TN for test); nnnnnn will be the sequence number of the file in question; and xxx will be the file type (ERR, FRJ or DXR) as detailed in 1.34 File naming conventions: (b) (c) (d) (e) Registration Data Update File: XOS01.PNnnnnnn.XDO Registration Data Refresh File also used for initial population: XOS02.PNnnnnnn.XDO Daily DCC Status Files: DCC01.PNnnnnnn.DXI Response Files from Daily DCC Status File processing will be: XOS01.PNnnnnnn.xxx Multiple file confirmation file where Registration Data has been split into multiple Registration Data Files: XOS02.PNnnnnnn.TOK 1.29 In the circumstance where Registration Data Files need to be split into multiple files due to size limitations; each Gas Network Party shall additionally provide a multiple file confirmation file confirming the number of files within the set as defined in 1.32(c) and with the file naming convention defined in 1.28(e) Each Gas Network Party shall ensure that all files (with the exception of the multiple file confirmation file as defined in 1.32(c)) contain header and trailer records that conform to the formats as detailed below. File Header Field Name Length Description 02.Registration_Data_Interface_Specification_consultation_version 12

13 Transaction Organisation Id Text 3 Value: A00 Numeric 10 An reference which uniquely identifies the sending System User / Organisation For example: DCC is File Text 3 An application specific code used to identify the structure and the usage of the file. The allowable values are: XDO ERR FRJ DXI DXR Registration Data File Response File - record level validation failure Response File - file level validation failure DCC Status File Response File - DCC Status update response Creation Date Date 8 The date on which the file was generated. Format : YYYYMMDD Creation Time Text 8 The time (UTC) at which the file was generated (within the Creation Date) Generation Number Format : HHMMSS Numeric 6 A sequence number which represents an issue of a file from the Network Party or DCC (indicated by the organisation id). Each file sent either from the Network Party to DCC or from DCC to the Network Party will have a unique consecutively increasing number. File Trailer Field Name Length Description Transaction Record Count Text 3 Value: Z99 Numeric 10 The number of detail records contained within the file. This should not include the standard header and the standard trailer but should include any file specific headers if specified for this file i.e. only A00 and Z99 records are excluded. 02.Registration_Data_Interface_Specification_consultation_version 13

14 1.31 Each Gas Network Party shall provide daily Registration Data Update Files irrespective of whether there are Registration Data updates to convey. Where there are no updates to provide the Registration Data Update File will contain the standard header, file sequence number and trailer and no data records Each Gas Network Party shall provide files to the DCC conforming to the following data flow structures: Registration Data Update Files Registration Data updates shall be contained within a single file type (Ref XDO) and shall consist of up to 3 different types of data record per update as detailed below. Where Registration Data needs to be split into multiple Registration Data Update Files due to size limitations, the data for a specific MPRN shall not be split between files. (i) Data Notifications (Ref E47, including data items for the Supply Meter Point such as Address, Postcode & UPRN) Field Name Optionality Length Description Transaction Meter Point Reference MPRN Status Source Registration Id Mandatory Text 3 Value: E47 Mandatory Number 10 A unique identifier for the point at which a meter is, has been or will be connected to the gas network. Mandatory Text 2 The current status of the operability of the meter. Mandatory Text 3 Unique ID to identify the GT or igt which has sent the data. 02.Registration_Data_Interface_Specification_consultation_version 14

15 Field Name Optionality Length Description Meter Point Address Meter Point Postcode Market Sector Flag Unique Property Reference Number Optional Text 250 Standard PAF Format Address for the Supply Meter Point. This field will be a concatenated form of the elements of the Supply Meter Point Address available. The address will be separated within the text delimiters (double quotation marks) by commas. The address will be represented in a consistent manner in the following order: Plot Number, Building Number, Sub Building Name, Building Name, Principal Street, Dependent Locality Post Town. If no address field data has been provided, the field will be blank denoted as ",,,,,," Optional Text 9 Standard PAF Post Code as defined in the PAF digest. The postcode will comprise the concatenated outcode and incode, separated by a space. Optional Text 1 A code that specifies that the site is used for Domestic or Industrial purposes. The allowable values are: D Domestic or I Industrial. Optional Text 12 A Unique Property Reference Number. It is a unique reference number that can be linked to further address information that is collated and provided by the Ordnance Survey Group. This field will not be populated until governance is agreed. (delivered as Null) (ii) Organisation Notifications (Ref. E48, including details of the various organisations associated with the MPRN such as Supplier, Meter Asset Manager and Network Operator). Field Name Optionality Length Description Transaction Mandatory Text 3 Value: E48 02.Registration_Data_Interface_Specification_consultation_version 15

16 Field Name Optionality Length Description Organisation Organisation Identifier Organisation Effective From Date Organisation Effective To Date Mandatory Text 3 A three character short code denoting the role performed by the Organisation being notified as being effective at the Supply Meter Point denoted in the parent record. The allowable values are: SUP Supplier; MAM Meter Asset Manager; NWO Network Operator. Mandatory Text 3 A three character short code which is assigned by the Transporter to denote the identity of the Organisation being notified as being effective at the Supply Meter Point denoted in the parent record. Mandatory Date 8 The date from which the Organisation was effective from or appointed to the Supply Meter Point denoted in the parent record. Format : YYYYMMDD Optional Date 8 Organisation s Effective To Date. Format : YYYYMMDD N.B. Where the date is , this will be treated as Null This will not be provided for Meter Asset Manager and Network Operator. (iii) Organisation Deletions (Ref. E49, including details of the various organisations previously associated with the MPRN which are now to be deleted). This record type is used to delete future dated organisations which will no longer come into effect due to other data changes. For example where a new Meter Asset Manager is due to be associated with an MPRN, but a change of supplier occurs before the effective date and the supplier assigns their own Meter Asset Manager. 02.Registration_Data_Interface_Specification_consultation_version 16

17 Field Name Optionality Length Description Transaction Organisation Organisation Identifier Organisation Effective From Date Organisation Effective To Date Mandatory Text 3 Value: E49 Mandatory Text 3 A three character short code denoting the role performed by the Organisation being notified as being effective at the Supply Meter Point denoted in the parent record. The allowable values are: SUP Supplier; MAM Meter Asset Manager; NWO Network Operator. Mandatory Text 3 A three character short code which is assigned by the Transporter to denote the identity of the Organisation being notified as being effective at the Supply Meter Point denoted in the parent record. Mandatory Date 8 The date from which the Organisation was effective from or appointed to the Supply Meter Point denoted in the parent record. Format : YYYYMMDD Optional Date 8 Organisation s Effective To Date. Format : YYYYMMDD NB Where the date is , this will be treated as Null (b) Response File - DCC Status update responses Following the processing of the DCC Status File (file format described in 1.33) each Gas Network Party shall provide a Response File indicating whether each of the DCC Status update records (record reference E45 ) was accepted or rejected. For each E45 record in the incoming DXI DCC Status File there will be a corresponding E46 record (as described immediately below) in the DXR Response File. If the E45 record is processed successfully, the outcome code in the E46 record will be "AC" and if unsuccessful the outcome code is RJ. Where the outcome is RJ the rejection reason will be notified to the DCC through an S72 record or records directly following the E Registration_Data_Interface_Specification_consultation_version 17

18 (i) The format of an E46 record is as follows: Field Name Optionality Length Description Transaction Mandatory Text 3 Value: E46 Outcome Code Mandatory Text 2 Details whether the request has been accepted or rejected. AC Accepted RJ Rejected. Meter Point Reference Mandatory Number 10 DCC Service Flag DCC Service Effective From Date Mandatory Text 1 Service flag provided by the DCC. The allowable values are: A Active S Suspended W Withdrawn Mandatory Date 8 The date the DCC Service Flag (provided above) is effective from. Format : YYYYMMDD (ii) The format of an S72 record is as follows: Field Name Transaction Rejection Code Optionality Length Description Mandatory Text 3 Value: S72 Mandatory Text 8 The unique reference number identifying the reason for the validation failure. One of the following two values: MPO00001 Supply Meter Point does not exist DCC00001 DCC Service Flag value is not recognised (c) Multiple file confirmation file Where Registration Data needs to be split into multiple files due to size limitations, each Gas Network Party shall provide an additional file confirming the number of files within the set. 02.Registration_Data_Interface_Specification_consultation_version 18

19 Field Name Optionality Length Description File Name Mandatory Text 18 Record Count Mandatory Number 10 The number of detail records contained within the file. This should not include the standard header and the standard trailer but should include any file specific headers if specified for this file i.e. only A00 and Z99 records are excluded The DCC shall provide files to each Gas Network Party conforming to the following data flow structure: DCC Status File To notify each Gas Network Party of DCC Status updates the DCC shall send a single DCC Status File (Ref DXI) that shall consist of a single data record per update (Ref. E45). The format of an E45 record is as follows: Field Name Optionality Length Description Transaction Meter Point Reference DCC Service Flag DCC Service Effective From Date (b) Mandatory Text 3 Value: E45 Mandatory Number 10 Mandatory Text 1 Service flag provided by the DCC. The allowable values are: A Active S Suspended W Withdrawn Mandatory Date 8 The date the DCC Service Flag (provided above) is effective from. Format : YYYYMMDD 02.Registration_Data_Interface_Specification_consultation_version 19

20 1.34 Each Gas Network Party shall create and send the Response Files as defined in 1.34 and (b) below, in response to failures in validation of the DCC Status File. On receipt of the Response File DCC shall raise an Incident as defined in the DCC Registration Data Incident Management Policy. Record level format failure Response File To record any record level format validation errors found in processing the DCC Status File, the Gas Network Party shall create a Response File with header and trailer as defined in 1.30 and one or more record level error records as detailed below. The file name will be as defined in 1.28(d) with suffix ERR. Field Name Optionality Length Description Transaction Rejection Code File Reference Rejection Description Mandatory Text 3 Value: E01 Mandatory Text 8 The unique reference number identifying the reason for the validation failure as defined in the Error Code under 1.34(c) Mandatory Number 10 The unique reference number of the file that was received and processed. Mandatory Text 250 Description of the error found and which record/field it occurred as defined in the Rejection Reason under 1.34(c). (b) Response File - File level rejection To record any file level format validation errors found in processing the DCC Status File, the Network Party shall create a Response File with header and trailer as defined in 1.30 and the file name will be as defined in 1.28(d) with suffix FRJ. File level validation failures will be contained within a single file and will consist of 2 different types of data record per file Rejected File (record reference S71) and Rejection Details (record reference S72). There will be one S71 record followed by one or more S72 records. 02.Registration_Data_Interface_Specification_consultation_version 20

21 (i) The format of an S71 record is as follows: Field Name Optionality Length Description Transaction Mandatory Text 3 Value: S71 File Reference Mandatory Text 30 The unique reference number of the file that was received and processed. (ii) The format of an S72 record is as follows: Field Name Optionality Length Description Transaction Rejection Code Mandatory Text 3 Value: S72 Mandatory Text 8 The unique reference number identifying the reason for the validation failure as defined in the Error Code under 1.34(d) (c) Record level - Error codes Error Code CSV00010 CSV00011 CSV00012 CSV00013 CSV00014 CSV00015 CSV00019 CSV00020 CSV00021 CHK00036 Rejection Reason Transaction type not recognized - <Record identifier> Invalid character - <Record identifier>, <Field number> Invalid numeric field, <Record identifier>, <Field number> Premature end of record - <Record identifier> Invalid record termination - <Record identifier> Invalid text field - <Record identifier>, <Field number> Record too short - <Record identifier> Mandatory field expected - <Record identifier>, <Field number> Invalid Date/Time field - <Record identifier>, <Field number> Mandatory record not supplied - <Record identifier> 02.Registration_Data_Interface_Specification_consultation_version 21

22 (d) File level - Error codes Error Code FIL00013 FIL00014 FIL00015 FIL00016 FIL00017 FIL00018 FIL00019 Rejection Reason Organisation ID on Header cannot be found Organisation ID on the Header does not match the Sender's ID File on the Header is not the same as that in File Name Generation Number on the Header is not the same as that in File Name A file has previously been received & processed with this Generation Number A count of Detail Records in the File does not match that held on the Trailer Invalid Record found 02.Registration_Data_Interface_Specification_consultation_version 22