DSD002 Annex 2 Reference	Category	Sub-Category	Title	Requirement Description
9.1.4	Performance Efficiency	Time behaviour	API Message Capacity	All services shall have the capability to control the number of Messages that are sent within a single API call
9.9	Security	Non-repudiation	Sender Unique Reference/ Transaction ID	All Services shall use DIP generated Transaction IDs returned in the response body of the API transaction to map against Messages for audit and tracking purposes
9.9.1 and 9.10	Reliability	Availability	Back Off & Retry	Each service after invoking a DIP API shall implement an exponential backoff and retry with jitter policy in the event of a comms failure with the DIP resulting from a http 429 response
7.12.4, 9.1.4, 9.9.1 and 9.10	Reliability	Availability	Message/Event Buffering	In the event of a failure to communicate with the DIP, the Service shall be able to buffer Messages for a period of at least 72 hours
4.3 and 7.11	Security	Authenticity	Signing Messages	All services shall check that Messages are digitally signed with the correct certificate from the Sender of the Message
7.4.6 and 9.1	Usability	Operability	Error Reporting	When Level 3 validation fails, e.g. when payload contents cannot be reconciled (schema validation), a response with the corresponding error code shall be reported back to the DIP via the http response in the webhook callback
9.7	Reliability	Fault Tolerance	Idempotency (SUR)	DIP User systems shall check for duplicate Messages with the same Sender Unique Reference under Level 3 or Level 4 validation
9.7	Reliability	Fault Tolerance	Idempotency (Transaction ID)	DIP User systems shall check for duplicate Messages with the same Transaction ID under Level 3 or Level 4 validation

7.4	Performance Efficiency	Resource Utilisation	Message/Event Consumption	DIP Users shall be able to process Messages at their own speed, independently to other consumers
9.7	Reliability	Fault Tolerance	Idempotency	In terms of handling Messages all DIP User systems shall be idempotent and have mechanism for handling duplicate messages
11.3.3	Performance Efficiency	Time behaviour	Level 3 Processing Times (synchronous)	All Services shall provide an initial synchronous response (Level 3 validation) to a Message within the following timeframes: up to average hourly volume, mean response time of 2s or less up to average hourly volume, 90th percentile response time of 4s or less from average hourly to peak hourly volume, mean response time of 5s or less from average hourly to peak hourly volume, 90th percentile response time of 8s or less
11.4.2	Performance Efficiency	Time behaviour	Level 4 Processing Times (Asynchronous)	BSC’s Data Acquisition Hub (DAH) shall have an asynchronous response time of 10 minutes or less. All Registration Services (REGS), Unmetered Supplies Operators (UMSO) and Distributors (DNOs/iDNOs) shall have an asynchronous response time of 60 minutes or less within normal operating hours. All other services shall provide an asynchronous response (Level 4 validation) to a Message within the following timeframes up to average hourly volume, mean response time of 6s or less up to average hourly volume, 90th percentile response time of 12s or less from average hourly to peak hourly volume, mean response time of 10s or less from average hourly to peak hourly volume, 90th percentile response time of 16s or less
9.8	Performance Efficiency	Capacity	Message Throughput	All Services (see exceptions) shall have capacity to process the following volumes of Messages: average daily volume of 66,000 peak daily volume of 300,000 average hourly volume of 2,750 peak hourly volume of 35,000 annual volume of 24M
9.8	Performance Efficiency	Capacity	Message Throughput (Secure Active)	All Services (unless explicitly referenced) shall have capacity to process the following volumes of Messages: peak daily volume of 1,143,000 * portfolio coefficient peak hourly volume of 1,143,000* portfolio coefficient ¶

CONTENTS

DSD002 Annex 1 V2.0

Defined Terms

Cross-references