DSD002 – DIP Connection and Operation
DSD002 relating to the connection requirements for DIP Users.
1. Reference is made to the DIP Supplement of the Balancing and Settlement Code.
2. This is DIP Subsidiary Document DSD002, Version 1.0 relating to the connection and operation requirements for the DIP and DIP Users.
3. This DSD is effective from 01 October 2024.
4. This DSD has been approved by the DIP Manager.
The purpose of this DSD is to set out the process that DIP Applicants and DIP Users must follow so that they can use the DIP.
DIP On-boarding ensures that all those participants wishing to use the DIP have developed their systems and processes to the required level to use the DIP in such a way so that messages are delivered in the correct way, data management processes and legislation are adhered to and there is no impact on other DIP Users.
Off-boarding ensures that there is a smooth departure from the DIP, messages are ‘re-directed’ (sent to the new Supplier) in the event of a Supplier failure or market departure, and Digital Certificates are revoked at the right time.
The DIP operations describes how the DIP will work and what DIP Participants should expect from the DIP.
The requirements for connection as laid out in this DSD will remain extant for the duration of being a DIP User.
2.1.1 The following organisations (or the organisation responsible for providing the service) shall be eligible to be DIP Users:
Supplier (SUP);
Metering Services Smart (MSS);
Metering Services Advanced (MSA);
Smart Data Services (SDS);
Advanced Data Service (ADS);
Unmetered Supplies Data Service (UMSDS);
Electricity Enquiry Service (EES);
Registration Service (REGS);
Unmetered Supplies Operator (UMSO);
Distributor (DNO/iDNO);
DIP Connection Provider (DCP);
The BSC’s Data Acquisition Hub (DAH); and
Meter Data Recorders (where they ‘opt-in’ to the DIP).
2.1.2 Where a DIP Applicant is required to undertake Industry Code Qualification ("relevant entry and qualification processes"):
that DIP Applicant may apply for, and commence, DIP On-Boarding concurrently with such relevant entry and qualification processes;
the DIP Manager will, where applicable and to the extent reasonably practicable, co-operate with the relevant Code Bodies in order to facilitate DIP On-Boarding and the other relevant entry and qualification processes and provide such information to relevant Code Bodies as may be provided for in this DSD002; and
the DIP Manager shall not approve the DIP On-Boarding of a DIP Applicant unless at the time of any such notification, that DIP Applicant’s DIP On-Boarding remains current.
2.2 Dual Industry Code Qualification route to DIP On-Boarding
2.2.1 This On-Boarding route shall apply to DIP Applicants that will undertake Industry Code Qualification under both the REC and the BSC, and applies where RECCo has shared DIP Applicant details with BSCCo for the purpose of initiating DIP On-Boarding.
2.2.2 Where a DIP Applicant is required to undertake Industry Code Qualification under the REC and BSC by virtue of their market role, BSCCo shall submit the relevant details (i.e. the details set out in this DSD) to the DIP.
2.3 Single Industry Code Qualification route to DIP On-Boarding
2.3.1 For DIP Applicants that are undertaking Industry Code Qualification for the BSC only, BSCCo will submit their relevant details to the DIP Portal as set out above.
2.3.2 Applicants that are undertaking Industry Code Qualification for an Industry Code that is not the BSC shall commence DIP On-Boarding as directed by the relevant Code Manager.
2.4 Non Industry Code Qualification route to On-boarding
2.4.1 Applicants that are not required to undertake
Industry Code Qualification under the BSC or REC shall apply directly to the DIP via the
DIP Portal front page –
energydataintegrationplatform.co.uk.
2.4.2 Where DIP Applicants apply via the DIP instead of the applicable Code Body, the DIP Manager shall:
refer them to the appropriate Code Body; and
if applicable, share with the Code Body any information that has been submitted to the DIP Manager.
2.5.1 Within the DIP there are four DIP User member roles which can be assigned. Any person within a DIP Applicant organisation can have either a single role or, be assigned multiple roles (allowing all four assigned to one person):
User Administrator (Admin) – The User Admin role, when assigned to any DIP Member, provides the functions to add other internal users and DCPs, and manage DIP IDs. The User Admin will complete the initial application, whether via an Industry Code or otherwise;
Certificate Admin – The person responsible for all certificate management, including registration, verification, completion of the certificate upload, and ongoing certificate maintenance. Given the scope of the role this may be multiple people at different parts of the process to allow for absence period and such like. This may also be undertaken by someone outside the DIP Applicant’s organisation where the DIP Applicant intends to engage a DCP;
Message Admin – The person with control and ownership of all activities relating to Message processing, replay and management; and
Analytics Reader – Persons that only have access to review the DIP dashboard feature.
2.5.2 The first Certificate Admin appointed shall have the authority to make decisions for or on behalf of the organisation and will agree to the relevant terms and conditions of the DIP. The Certificate Admin shall be aware of Digital Certificate activities such as Certificate Signing Requests (CSRs) or Certificate Revocation Request (CRRs).
2.5.3 A DIP User using a Certificate Admin who is an employee of a DCP is ultimately responsible for ensuring that Certificate Admin complies with all relevant aspects of Digital Certificate management as set out in the DIP Rules. In all cases, the DIP User is responsible for compliance with the DIP Rules. Where Certificate Admin’s are employees of a different organisation, it is expected that there will be a commercial agreement between the Third Party and the DIP User.
2.5.4 Registered users can view the role(s) they have been assigned and the business services they can interact with.
2.5.5 The DIP Manager shall provide guidance on how authorised personnel can be amended.
2.6 DIP On-Boarding preparation
2.6.1 Prior to commencing DIP On-Boarding, DIP Applicants should familiarise themselves with the contents of this DSD. Specifically they should familiarise themselves with the specifications described in Annex Two and Annex Three of this DSD.
2.6.2 Prior to commencing DIP On-Boarding, DIP Applicants shall prepare the following information:
name of MP User Admin;
company number;
company name;
company address;
email address for the purpose of notices and other formal communications (and DIP User’s agree to notify the DIP Manager immediately following any change to such email address);
MPID and Market Roles (if known);
requested DIP Role;
whether the company is providing DCP services (this will determine how they are registered in the DIP as the DCP registration leads to the allocation of a DCP ID – see below); and
additional company contact (if applicable).
2.6.3 The above information will either be submitted to a Code Body as part of their Industry Code application, or directly to the DIP dependant on which route applies.
2.7 Compliance with DIP Rules
2.7.1 All DIP Applicants must agree to comply with the DIP Rules during the initial DIP On-Boarding application review.
2.7.2 DIP Applicants that are also going through the process of acceding to the BSC will do this by virtue of commencing the BSC qualification process. Other DIP Applicants shall enter into an Access Agreement (DSD002 Annex 4 ‘Access Agreement’) with the DIP Manager to the effect that they agree to the requirements within the DIP Rules.
2.7.3 DIP On-Boarding will not complete until an Access Agreement has been executed and is effective. The DIP Manager shall ensure that the Access Agreement does not place any more obligations on non-BSC Parties than BSC Parties.
2.8.1 The DIP Manager initial checks shall assess the suitability of the application, including:
DIP Applicant’s, User Admin’s and Certificate Admin’s presence on publicly available sources and alignment to their application;
whether the DIP Applicant already has a Licence e.g. they already operating in a Licensed capacity that does not require DIP access and they are expanding their business to include an activity that will require DIP access;
whether the DIP Applicant is already in the energy industry undertaking a different role;
whether the Code Bodies have received applications for Industry Code Qualification or if the DIP Applicant is already so qualified;
meeting with the User Admin and/or Certificate Admin to discuss their application and plan for DIP On-Boarding and subsequent operation; and
requesting a written attestation as to why the DIP Applicant wishes to become a DIP User.
2.8.2 The DIP Manager may take any measure they deem appropriate to satisfy themselves that the application is valid and that the DIP Applicant has an appropriate reason to be a DIP User.
2.8.3 The DIP Manager shall discuss with the DIP Applicant what checks they will undertake and what evidence the DIP Applicant will be required to provide.
2.8.4 The DIP Manager shall liaise with Code Bodies to understand what checks/evidence they have in respect of the application and whether it is applicable to the DIP Manager’s checks. If BSCCo and/or RECCo has information that may be useful, and they are able to share with the DIP Manager, the DIP Manager may use this information in undertaking its own checks instead of asking for further information from the DIP Applicant.
2.8.5 Where a Code Body wishes a DIP Applicant that is undergoing DIP On-boarding as a requirement of said Industry Code not to begin DIP On-Boarding for whatever reason, the DIP Manager shall consider their request and act accordingly.
2.8.6 The DIP Manager shall take into account a DIP Applicant’s need to undertake DIP On-Boarding as part of an Industry Code accession. The DIP Manager shall work with the DIP Applicant and the relevant Code Body with a view to resolving any issues arising.
2.9.1 Once the DIP Manager has satisfied itself that an application is valid, the DIP Manager will send a Redemption Link to the Certificate Admin. At the same time the DIP Manager will inform the Code Bodies that the DIP Applicant has completed the DIP Manager’s initial checks.
2.9.2 The Certificate Admin will undergo verification with the DIP Verification Service Provider.
2.9.3 The DIP Manager shall provide guidance on how to complete the Certificate Admin sign-in process.
2.10 Organisational set-up
2.10.1 The fundamental basis for an organisational set-up within the DIP is that all levels within the DIP User’s Corporate Group shall share the same DNS Domain Name as the parent/umbrella organisation. This applies in relation to Market Participant Organisations (MPOs) where they are an Affiliate of the parent/umbrella organisation. The organisational set-up in this section is only applicable to the DIP for the purpose of message routing and validation and is not a requirement elsewhere (e.g. in an Industry Code).
2.10.2 The DIP User may establish as many MPOs as fits their business model. This organisational approach recognises that each MPO shall have its own unique Company Number. Where a DIP User is comprised of a single company, or where it is organised in such a way that only a single company is a DIP User, that company shall be a single MPO (regardless of how many market roles it has registered).
2.10.3 It is possible for MPIDs to be shared across different DIP Roles, so long as the MPID and role code have a unique DIP ID associated with them as demonstrated in the examples below.
Example of a DIP User’s organisational set-up – Multiple companies under one umbrella:
Example of a DIP User’s organisational set-up – One company, multiple Market Roles
2.10.4 Where a DIP User will be a DCP, this shall be the equivalent of a MPO in the organisation hierarchy.
2.10.5 Not all industry participants will necessarily have a MPID if this is the case, the DIP Manager will advise on how best to set-up the hierarchy, but shall be guided by the above example and requirements.
Example of a DIP User’s organisational set-up – One Company, multiple DCP roles
2.11 Functional On-Boarding Checks
2.11.1 Functional Checks will take place within the DIP non-production environment. During this phase the DIP will auto-generate the MPO’s DIP IDs and DCP IDs as appropriate where the MPOs Market Role exists in the current ISD data set #45. Where the role does not exist, the creation of the DIP ID is at the discretion of the DIP Manager. The DIP ID will be sent to BSCCo’s Industry Standing Data (ISD) platform for inclusion in the appropriate ISD entities.
2.11.2 The DIP Applicant shall carry out the Digital Certificate exchange and API key generation processes during this stage – see DSD002 Annex 2 ‘Detailed DIP Operational Requirements’.
2.11.3 The DIP Applicant will be able to download a list of all of the Interfaces applicable to their Market Role as well as templates for each Interface.
2.11.4 The DIP Applicant will send a pre-agreed set of messages that represent the market roles they under undertaking. In addition, to sending one of each message format, the DIP Applicant shall send one of each message format that is incorrect to demonstrate that they can manage receipt of error messages from the DIP.
2.11.5 The DIP Applicant will be sent a pre-agreed set of messages that represent the market roles they under undertaking.
2.11.6 The DIP Manager shall publish guidance on how to complete functional checks.
2.12 Non-Functional On-Boarding Checks
2.12.1 For DIP Users with multiple MPOs, each MPO shall be subject to separate Non-Functional On-Boarding Checks. However, the DIP Manager shall recognise where there are replications between MPOs and shall allow one piece of evidence to apply equally to each connected MPO.
2.12.2 Non-Functional On-Boarding Checks will be carried out against the requirements of DSD002 Annex 1 ‘DIP On-Boarding Non-Functional Checks’. In carrying out the Non-Functional On-Boarding Checks, the DIP Manager shall take into account any commercial and/or legal restrictions and shall make allowances accordingly following discussion with the DIP Applicant.
2.12.3 The DIP Manager may conduct Non-Functional On-Boarding Checks themselves or engage a third party to conduct the checks on behalf of the DIP Manager. Where a third party is engaged by the DIP Manager:
The DIP Applicant shall co-operate with such third party as if they were the DIP Manager; and
The DIP Manager shall retain responsibility for ensuring checks are carried out in accordance with this DSD.
2.12.4 The means of carrying out DIP On-Boarding checks shall be discussed with the DIP Applicant before commencement.
2.12.5 Where Code Bodies carry out similar checks to these Non-Functional On-Boarding Checks as part of their Industry Code Qualification the DIP Manager may accept them as compliance with these checks. Similarly, where the DIP Manager’s checks could be of assistance to Code Bodies, the DIP manager may share their findings.
2.12.1 Where, at any point during the On-Boarding process the DIP Manager finds that the DIP Applicant is unable to adhere to the requirements of the DIP Rules, the DIP Manager shall raise this issue as soon as practicable with the DIP Applicant.
2.13.2 Where the time frame for resolution may delay Industry Code Qualification, the DIP Manager shall inform the relevant Code Bodies of the delay and resolution, ensuring that the DIP Applicant is kept informed of any communications and agreements between the DIP Manager and relevant Code Bodies.
2.13.3 Where the DIP Manager and DIP Applicant are unable to agree a resolution plan, the DIP Manager shall consider whether or not to proceed with other checks, or suspend DIP On-Boarding until such time as the issue can be resolved.
2.13.4 Where the DIP Manager suspends DIP On-Boarding, and the DIP Applicant is undergoing Industry Code Qualification, the respective Code Bodies shall be informed. The DIP Manager shall discuss with the relevant Code Bodies whether such Code Body is/are able to help resolve the issue.
2.14 Move to Production Environment
2.14.1 Following successful completion of the checks outlined above, the DIP Applicant and the relevant Code Bodies shall be informed that DIP On-Boarding is complete.
2.14.2 DIP Applicants that are also undergoing Industry Code Qualification shall not proceed further with this process until the relevant Code Bodies have informed the DIP Manager that Industry Code Qualification is complete.
2.14.3 DIP Applicants that are not undergoing Industry Code Qualification, and DIP Applicants that have completed Industry Code Qualification (and the Code Body has informed the DIP Manager to that effect) will be moved to the Production Environment. However, prior to moving to the Production Environment, the DIP Manager shall confirm that the information provided as part of DIP On-Boarding remains correct.
2.14.4 The DIP Service Provider will promote the DIP User to the Production Environment. The DIP User will then need to access Digital Certificates for the Production Environment – the DIP Manager shall maintain guidance on how to do this. At the same time, the DIP will ratify ISD data to ensure the data in the DIP tallies with ISD.
2.14.5 The DIP Manager shall inform the Code Bodies that the DIP User has been moved to the Production Environment.
2.14.6 Once the DIP User has accessed Production Environment Digital Certificates, and the DIP Manager has confirmed this, the DIP User will be entitled to use the DIP as intended.
2.14.7 Following completion of a DIP User’s successful move to the Production Environment, the DIP Manager will publish this.
2.15 Non Market Participants
2.15.1 Organisations that request to become a DIP User that are not listed in paragraph 2.1 may apply to on-board. In such cases the DIP Manager shall determine whether they shall be allowed to on-board. In making its determination the DIP Manager may liaise with Code Bodies and/or the Authority in order to gather views and/or whether they are aware of the DIP Applicant and its need to access the DIP.
2.15.2 The DIP Manager shall direct that DIP On-Boarding shall follow the process in this DSD so far as practicable.
2.15.3 Alternately, the DIP Manager should consider whether it is appropriate to create a new DIP User type and propose a DIP CR to add them to paragraph 2.1. In this case, once the new DIP User type has been created, the non-Market Participant will carry out DIP On-Boarding in the normal way.
2.16 DIP On-Boarding fees
2.16.1 Applicants that are applying to on-board and are listed in paragraph 2.1 shall not be subject to DIP On-Boarding fees.
2.16.2 Any other DIP Applicant that the DIP Manager approves for on-boarding shall be subject to a DIP On-Boarding fee. The amount to be charged shall be determined by the DIP Manager and communicated to the DIP Applicant prior to DIP On-Boarding commencing.
2.16.3 The DIP Manager may require the DIP Applicant to pay some or all of the DIP On-Boarding fee in advance of commencing DIP On-Boarding and further, may require the adherence to a payment plan whereby fees shall be paid at certain points in DIP On-Boarding.
2.16.4 The DIP Applicant shall not be promoted to the Production Environment until all necessary DIP On-Boarding fees have been received.
2.17.1 Where a DIP User wishes to change their DIP Role, they shall submit their Digital Certificates for their current role (essentially DIP Off-Boarding) and undertake DIP On-Boarding to the DIP in their new role.
2.17.2 Notwithstanding the previous paragraph, the DIP Manager shall liaise with the DIP User and Code Bodies to agree dates for the revocation of old Digital Certificates (i.e. the date on which the DIP User off-boards) including to confirm whether any of the other provisions of this DSD may be applicable to that particular DIP User.
2.17.3 Where the DIP Manager is satisfied that the DIP User need not undergo full DIP On-Boarding for their new role, it shall agree with the DIP User and relevant Code Bodies a bespoke DIP On-Boarding for the new DIP Role. The DIP Manager shall, in considering exercising this provision, take into account a number of factors including:
whether the DIP User will be undertaking Industry Code Qualification;
the need for good governance and clarity;
whether any checks would involve disproportionate effort for the DIP Manager, Code Bodies and/or the DIP User;
whether any efficiencies in the process could be achieved, taking into account the relevant circumstances;
the requirements for reinstatement later in this DSD, to the extent that they may apply to this paragraph; and
whether a bespoke DIP On-boarding is fair to other DIP Users.
2.17.4 The bespoke DIP On-boarding for the new DIP Role shall align as closely as practicable with the normal DIP On-boarding requirements and the DIP Manager shall ensure that it is applied in a non-discriminatory way.
2.18 Additional DIP Roles
2.18.1 Where a DIP User wishes to undertake additional DIP Roles they shall apply for that role as though they were applying as a new DIP Applicant and undertake DIP On-Boarding.
2.18.2 The DIP Manager may allow a tailored DIP On-Boarding to occur based on the particular circumstances.
3.1 DIP Access Suspension
3.1.1 Subject always to the DIP Manager’s rights on emergency suspension and any provisions in terms and/or agreement between the DIP User and the DIP Service Provider and/or DIP Verification Service Provider, the DIP Manager shall not suspend any DIP User’s access to the DIP without first conferring with the DCAB
3.1.2 Subject always to the DIP Manager’s rights on emergency suspension the DIP Manager may suspend DIP User(s)’ access to the DIP pursuant to this paragraph for reasons including:
as part of a response to a breach of the DIP Rules where such action is a consequence of said breach;
following a breach of an Industry Code where the DIP Manager has agreed to a suspension as part of a wider package of enforcement activity;
where the DIP User has/is using the DIP in any way that is contrary to the Fair Use Requirement.
3.1.3 The DIP Manager may only suspend a DIP User’s access to the DIP for as long as it takes to resolve the situation and/or determine that the incident giving rise to the suspension is not as serious as first thought (whichever comes first).
3.1.4 The DIP Manager shall reinstate the DIP Users access to the DIP, and revoke suspension as soon as practicably possible after the situation giving rise to the suspension has been resolved to the DIP Manager’s satisfaction.
3.1.5 When a situation is resolved (including emergency suspension – see below) the DIP Manager shall inform Code Bodies as soon as reasonably practicable thereafter. The DIP Manager shall, before revoking any suspension, seek the views of impacted Code Bodies in respect of their Industry Codes.
3.2.1 The DIP Manager may suspend any DIP User’s access to the DIP wholly (all entities within a domain), or in part (specific MPOs and their DIP IDs, or specific DIP IDs) in an emergency.
3.2.2 Events that may be considered an emergency shall include:
serious data breach by DIP User;
serious Cyber Security Incident with the DIP User’s system that may impact other DIP Users; and
DIP User has caused the introduction of Malware.
3.2.3 Where the DIP Manager suspends a DIP User’s access in any way, they shall attempt to inform Code Bodies and the Authority of their intent first.
3.2.4 If not practicable, or if the urgency of the situation means this is not possible, the DIP Manager shall take the required action first and inform Code Bodies and the Authority retrospectively.
3.2.5 If not practicable, or the urgency of the situation means this is not possible, the DIP Service Provider or DIP Verification Service Provider may suspend a DIP User’s access first and inform the DIP Manager retrospectively.
3.2.6 If the DIP Service Provider or DIP Verification Service Provider takes action before they are able to inform the DIP Manager, the DIP Manager shall then assess whether they would have taken the same action.
3.2.7 Where the DIP Manager determines they would have taken the same action as the DIP Service Provider or DIP Verification Service Provider, then any subsequent actions shall be taken in accordance with the DIP Rules as if the DIP Manager suspended the DIP User’s access themselves; otherwise the suspension shall be reversed as soon as practicable.
4.1 Conditions for DIP Off-boarding
4.1.1 The two circumstances in which DIP Users may be subject to DIP Off-Boarding include:
voluntary DIP Off-Boarding – where a DIP User chooses to leave the DIP of their own volition, e.g. as part of leaving the electricity market; and
mandatory DIP Off-Boarding – the DIP Manager removes access to the DIP, this could include as a consequence of a breach of DIP Rules and/or any Industry Code or following Authority decision.
4.1.2 Regardless of the reason for revocation, it cannot occur until:
the DIP Manager agrees;
all outstanding DIP Charges have been paid in the case of a DIP Payee (unless otherwise waived by the DIP Manager having first consulted with the DCAB);
Code Bodies have agreed – this is particularly applicable where the DIP User has outstanding/forthcoming obligations under an Industry Code;
ISD has been updated and the ‘effective-to-date’ (see example in paragraph 5) has been populated to reflect their departure from the DIP; and
other DIP users have been informed and sufficient time has been allowed (based on the circumstances of the case) for any mitigating actions on the part of remaining DIP Users.
4.1.3 Subject to the circumstances of the case, setting an ‘Effective to Date’ should be considered as the default means for removal of a DIP Role and/or departure from the DIP.
4.2 Voluntary DIP Off-Boarding
4.2.1 Where a DIP User no longer wishes to be a DIP User, they may make such request to the DIP Manager.
4.2.2 The revoking DIP User should provide:
reason for no longer wishing to be a DIP User;
proposed DIP departure date;
if applicable, whether the Code Bodies for the Industry Code(s) to which they are a Party have been informed; and
any other assurances and/or information as required elsewhere in the DIP Rules.
4.2.3 Where the DIP Manager receives a notice of voluntary revocation of DIP access, it shall inform the relevant Code Bodies for any objection they may have to the DIP User’s departure from the DIP.
4.2.4 The DIP Manager, in conjunction with the departing DIP User and (if applicable) Code Bodies shall agree the date for revocation of access and any actions that may be required prior to the DIP departure date (including any actions by other DIP Users to mitigate the Off-Boarding DIP User’s departure). The DIP User’s access will not be revoked until all actions required by Code Bodies and/or the Authority or other appropriate authority have been completed.
4.2.5 The DIP Manager shall liaise with the DIP Service Provider to ensure all Digital Certificates are end-dated to the agreed DIP departure date.
4.2.6 The DIP Manager shall liaise with BSCCo to ensure the ISD entities are updated to reflect the DIP Users departure and their departure date (‘effective to date’ in ISD).
4.3 Involuntary DIP Off-Boarding
4.3.1 The DIP Manager shall not remove any DIP Users from the DIP in accordance with this paragraph without first conferring with the DCAB.
4.3.2 The reasons the DIP Manager may revoke access may include:
serious data breach by DIP User;
serious Cyber Security Incident with the DIP User’s system that may impact other DIP Users;
DIP User is sending invalid data that is having a material impact on settlement operations; DIP User has knowingly caused the introduction of Malware;
as part of a pre-determined response to a breach of the DIP Rules; when any of the information in a Digital Certificate is known or suspected to be inaccurate;
upon suspected or known compromise of the Private Key associated with a Digital Certificate;
upon suspected or known compromise of the media holding the Private Key associated with a Digital Certificate;
following a breach of an Industry Code where the DIP Manager has agreed to DIP Off-Boarding as part of collective enforcement activity;
following a decision from the Authority;
where the DIP User has/is using the DIP in any way that is contrary to the Fair Use Requirement; and
where and a Supplier of Last Resort event occurs and the previous Supplier no longer requires DIP access
4.3.3 Where one of the above has occurred, but due to mitigating circumstances, involuntary DIP Off-Boarding is deemed not to be appropriate, other actions shall be considered such as suspension, action pursuant to an Industry Code, or referral to the Authority for enforcement action.
4.3.4 Where the DIP Manager determines, that a DIP User is to be removed from the DIP they shall inform the relevant Code Bodies and for them to raise any objection to the DIP User’s removal from the DIP.
4.3.5 The DIP Manager, in conjunction with Code Bodies and (if applicable) the departing DIP User, shall agree the date for revocation of access and any actions that may be required prior to the DIP departure date (including any actions by other DIP Users to mitigate the Off-Boarding DIP User’s departure).
4.3.6 The DIP User’s access will not be revoked until all actions required by Code Bodies or other appropriate authority (including the Authority if applicable) have been completed, so far as practicable.
4.3.7 The DIP Manager shall liaise with the DIP Service Provider to ensure all Digital Certificates are ended dated to the agreed DIP departure date.
4.3.8 The DIP Manager shall liaise with BSCCo to ensure the ISD entities are updated either on the DIP departure date, or as soon as practicable possible following, the DIP departure date.
4.4.1 Where a DIP User has multiple DIP Roles, and wishes to no longer undertake one of those DIP Roles, they shall inform the DIP Manager.
4.4.2 The DIP Manager shall liaise with Code Bodies and the DIP User, and the Authority if appropriate, to agree revocation dates (including any actions by other DIP Users to mitigate the Off-Boarding DIP User’s departure). This shall include timelines for Code Bodies to make the necessary corresponding changes to their Industry Code’s systems and records.
4.4.3 Once revocation has occurred, the DIP Manager shall confirm that the DIP has been updated accordingly and inform Code Bodies and the DIP User to that effect.
4.5 Return to the DIP following departure
4.5.1 Where an organisation’s access to the DIP has ceased (whether voluntarily or otherwise), but that organisation wishes to become a DIP User again, they shall first liaise with the DIP Manager.
4.5.2 The DIP Manager shall inform the Code Bodies of any such request and seek their views on whether the organisation should be permitted to undergo DIP On-Boarding again, and whether any Industry Code Qualification (or re-qualification) will also be required.
4.5.3 The DIP Manager shall inform the Authority and other relevant authorities if applicable that an organisation wishes to undertake DIP On-Boarding again.
4.5.4 Where there is no objection to the DIP Applicant undertaking DIP On-Boarding again, the DIP Manager shall review the DIP On-Boarding requirements and, in conjunction with the DIP Applicant, agree the best route forward whether that is full DIP On-Boarding or a bespoke package taking into account:
time away from the DIP;
whether the DIP Applicant is applying for the same Market Role(s) as before;
whether their organisational hierarchy will be the same;
the circumstances surrounding the DIP Applicant’s previous departure from the DIP; and
Code Bodies’ (where applicable) and the Authority’s views.
4.5.5 Once the DIP On-Boarding route has been determined, the DIP Manager shall inform the relevant Code Bodies and liaise with them to ensure the requirements of this DSD are adhered to as closely as practicable, being mindful of the specific circumstances of the application.
5 Supplier of Last Resort, Special Administration Regime, and Trade Sales
5.1 Supplier of Last Resort - preparation
5.1.1 As soon as the DIP Manager becomes aware of the point at which the Off-taking Supplier will take responsibility for the previous Supplier’s customers (the cut-over point), they shall liaise with the relevant parties, including the Code Bodies, to ensure timescales and requirements are aligned.
5.1.2 Given the design of the validation rules within the DIP, any message sent to the previous Supplier will cease to be routed to that Supplier after the “effective to date” (ETD) and will instead be routed to the Off-taking Supplier from the “effective from date” (EFD).
5.1.3 As part of the SOLR process the DIP Manager will ensure that the DIP has the latest ETD and EFD dates to allow ISD information to be updated by BSCCo.
5.2 Supplier of Last Resort – following switch over
5.2.1 Following cut-over the DIP Manager shall check that the previous Supplier is no longer receiving DIP data and that messages are being received by the Off-taking Supplier.
5.2.2 Having confirmed that the switch over was successful, the DIP Manager shall inform the relevant parties, including Code Bodies. It is expected that this will be reciprocated by Code Bodies once they have confirmed the switch over has been completed on their part.
5.3 Supplier of Last Resort – Removal from the DIP
5.3.1 Following the completion of the initial switch-over checks, the DIP Manager shall consider whether it is appropriate to remove the previous Supplier from the DIP. If the DIP Manager decides that removal from the DIP is appropriate in all respects it shall proceed in accordance with paragraph four amended as appropriate taking into account the circumstance of a SOLR event.
5.3.2 If the DIP Manager determines that the previous Supplier should no longer have the DIP Role of ‘Supplier’, or receives direction to that effect from the Authority, but it is still appropriate for the previous Supplier to retain other DIP Roles, then they shall act in accordance with the process for change of DIP Role amended as appropriate taking into account the circumstance of a SOLR event.
5.4.1 Where a Supplier is able to arrange for another Supplier to purchase their customers, this can be achieved as either:
a change of Supplier event i.e. the previous Supplier’s customers will be transferred to the new Suppliers MPID; or
the new Supplier could subsume the previous Supplier’s MPID into their portfolio.
5.4.2 If the ‘change of Supplier’ option is taken, each Supplier shall act in accordance with the relevant Industry Code requirements and once the change of Supplier process has completed, the previous Supplier shall act in accordance with this DSD in terms of revocations.
5.4.3 If the new Supplier subsumes the MPID the de-assignment and re-assignment of webhooks will need to occur – the DIP Manager will advise the best way to achieve this.
5.4.4 If the previous Supplier does not seek voluntary revocation in accordance with this DSD, then the DIP Manager may apply to the Authority to take the actions appropriate to the Trade Sale, and in doing so shall liaise with Code Bodies and the outgoing Supplier at each step.
6 Information Security Management Systems (ISMS)
6.1 ISMS Standards and Obligations
6.1.1 DIP Participants should have ISO 27001 certification or their ISMS should meet equivalent standards.
6.1.2 For clarity, if a DIP User does not have ISO 27001 certification, then their ISMS shall be equivalent to ISO 27001 requirements based on controls described within the ISO 27000 series.
6.1.3 The DIP Manager shall provide guidance on which parts of the ISO 27000 series they are applicable to DIP Users, but it is the responsibility of the DIP User to demonstrate equivalency. Means of demonstrating equivalency include:
Accreditation equivalent to ISO 27001;
A statement of applicability explaining how the DIP user’s ISMS is equivalent to ISO 27001; and
Where a DCP is used – the DCP’s ISO 27001 certification or equivalency.
6.1.4 Each DIP User, and the DIP Service Provider, shall demonstrate compliance with DIP ISMS requirements, and the DIP Manager shall validate (at their discretion, and in accordance with paragraph 2.13) such compliance:
as part of the DIP On-Boarding; and
thereafter, as part of the assurance and audit regimes described in DSD003 ‘Assurance and Reporting’.
6.1.5 Where a DIP user is demonstrating equivalency via 6.1.2 (c), and this changes, they shall give the DIP manager at least one-months’ notice and a proposal for how they will meet the requirements of this DSD. If compliance cannot be achieved, the DIP Manager will consider their options as laid out elsewhere in this DSD.
6.2.1 DIP Participants shall undertake Penetration Testing and vulnerability management testing routinely in accordance with Good Industry Practice and ISO 27001 requirements.
6.2.2 DIP Participants shall maintain a Cyber Incident response plan which may be part of a crisis management plan and which may also be comprised in wider organisational plan(s). DIP Users shall submit their Cyber Incident response plan to the DIP Manager for review as part of the DIP Manager’s assurance activities if required by the DIP Manager (or their representative).
6.2.3 DIP Participants shall periodically test their Cyber Incident response plans (where relevant in line with the ISO 27001 requirements). The results of such tests shall be retained for a minimum of 5 years and shall be presented to the DIP Manager when required.
Version | Date | Description of Change | Approval Reference |
1.0 | 01/10/2024 | 01 October 2024 Non-Standard Release | P353/08 |
