DH-800 End customer authorizations

The rights of Datahub parties are managed by agreements and by means of authorizations. There are two types of authorizations:

1. Authorizations issued by the customer, in which the customer provides consent for the processing of personal and electricity consumption data. The principle of these authorizations is described under number 1 in the figure below.

2. Delegations and party authorizations are arrangements between Datahub parties that allow one party to grant another the right to access its data or to perform specific tasks associated with a defined role. The principle of these delegations and party authorizations is described under numbers 2 (delegations and party authorizations issued by the supplier) and 3 (delegations and party authorizations issued by the DSO) in the figure below.

Open

Reporting authorizations and delegations to Datahub

Authorization principles in Datahub

The rights of Datahub parties to data stored in Datahub are governed by both agreements and authorizations. An end customer can give another Datahub party an authorization with which that party obtains the right to the customer’s proprietary data to the extent defined by the wording of the authorization. The end customer must provide a digital authorization directly to Datahub.

The new authorization service, which the customer accesses with Suomi.fi authentication, is the end customer’s user interface (UI) for creating and managing authorizations. Initially, the current end-customer portal functionality for authorization management will exist as well, but in the future customers may be redirected from there to the authorization service to manage authorizations.

A party can send an end customer an authorization request via Datahub. Then, the actual authorization will only be created in Datahub when the customer approves the authorization request in the authorization service.

Authorizations issued by the customer: types, purposes and validity

The customer authorizes a Datahub party to use their information for a specific purpose. The following table presents purposes for and types of authorizations in Datahub. The table provides a high-level overview of which types of information each authorization type grants access to.

The validity of the authorization must correspond to the period agreed upon with the customer. In the industry, fixed-term authorizations are generally recommended, but some types of authorizations may, if necessary, be valid until further notice. If a fixed-term service has been agreed upon with the customer, the authorizations must also be created as fixed-term.

Authorizations grant access to metering data only for the period during which the customer has held an agreement for the accounting point, up to a maximum of 6 years. When a customer authorizes a new supplier using the authorization type ‘Invitation to tender’, the supplier has the right to access the customer’s data for 30 days and can retrieve metering data for up to six years. A customer who is in the process of moving to a new accounting point cannot authorize a new supplier to access metering data, as they have not previously been a customer at that accounting point and therefore do not have any metering data until the moving date.

If the customer has had multiple agreements for the accounting point, and there has been another customer with an agreement in between, the authorization only grants access to data from the most recent agreement period.

Authorizations are stored in Datahub per customer and accounting point. An exception to this is the ‘Accounting points’ type of authorization, which is customer-specific and grants the authorized party the right to retrieve basic information about all of the customer’s accounting point, based on the customer’s identifier (business ID or personal ID). The customer can view the authorizations they have issued and their details (associated accounting point, recipient of the authorization, type of authorization, and validity period) in the authorization service.

Creating a new authorization

The customer issues an authorization to a supplier, a third party or balancing service provider, after which the party can retrieve the specified information from Datahub. According to the Electricity Market Act and current data protection regulation, a residential customer must personally issue an authorization directly to Datahub. Therefore, the residential customer always authenticates their identity using strong identification on the customer portal provided by Datahub. Suppliers and third parties can, temporarily, report a business customer’s authorization on behalf of the customer, using an authorization notification event, but the event will be discontinued once the authorization process reform is fully completed. After that, parties will send authorization requests to customers for approval through Datahub.

Customer creates authorization in the authorization service

The figure below demonstrates how a customer can create an authorization for another party in the authorization service (A1.). The authorization service sends the authorization to Datahub, where it is stored. Datahub forwards information about the new authorization to the authorized party (A2.), after which the information pursuant to the authorization can be disclosed to them from Datahub (A3.).

Correspondingly, authorizations may be created via the end-customer portal for as long as its functionality is supported alongside the new service.

Open

An end customer creates an authorization in the authorization service

Party sends authorization request to customer

To give parties better control of the authorizations they need, a party may send an authorization request via Datahub to the authorization service for a customer’s approval. In the figure below, a party creates an authorization either with a message or on the Datahub UI (B1.). Datahub forwards the authorization request to the authorization service and, should the party so wish, emails the customer a new authorization request notification (B2.). The customer logs onto the authorization service, where they can approve the authorization request (B3.). After that, the authorization is stored in Datahub, and the authorization data is sent to the authorized party (B4.), as in use case A in the preceding paragraph (Customer creates authorization in the authorization service).

Open

A party sends an authorization request to a customer for approval

A party may send an authorization request:

• For all of a single customer’s accounting points, in which case the customer’s identifier is specified in the request, but the accounting points are not differentiated.

• For one or more accounting points of a specific customer, in which case the customer’s identifier and the accounting points’ identifiers are specified.

Datahub verifies the scope for issuing authorizations as per the request. In other words, it verifies the existence of the customers and accounting points in Datahub and whether the customers hold agreements for any accounting points specified in the request, if the authorization type so requires. Datahub forwards a valid request to the authorization service. At this stage, no actual authorization is stored in Datahub. Instead, the authorization is only stored in Datahub when the customer has approved the request from the authorization service and the information about the new authorization(s) arrives from the authorization service to Datahub.

A party may set an expiration date for a request. If no expiration date is set, the request expires after the maximum period for all requests, one month. The authorization service returns data to Datahub indicating whether the customer has approved or rejected the request. If the customer approves the authorization request, authorizations are created in Datahub and the party receives notifications about these new authorizations. If the customer rejects the request, no authorizations are created. A party sees the status of authorization requests they have sent from Datahub.

Maintenance of authorizations

If a customer moves out of an accounting point for which they have issued authorizations, these authorizations are automatically ended in Datahub when the customer moves out. The customer’s authorizations are also automatically ended also in situations when the customer is marked as information-restricted (non-disclosure). A customer marked as information-restricted cannot issue authorizations.

The combination of customer, party, accounting point and authorization type cannot be duplicated in Datahub. Authorization notifications with the same combination of information overwrite the existing authorization. 

The party must terminate the authorizations received from the customer, for example, when the service relationship or contract between the party and the customer ends. Termination should not be left to the customer’s responsibility. The party can terminate the customer’s authorization in Datahub via a message or the user interface. It is also possible to cancel authorizations that are set to start in the future. A party can send a notification of termination/cancellation of authorization concerning:

• One or more specified accounting points

• All authorizations of a customer with a single request without specifying accounting points

• A specific type of authorization for all of the customer’s accounting points with a single request

In the user interface, authorizations can only be terminated or cancelled one at a time.

A party may also cancel an authorization request it has sent, either with a message or via the UI. In that case, the sent authorization request is cancelled in full. This means that if several accounting points are attached to the authorization request and an error is found in one of them, the whole request must be cancelled and redone without the erroneous accounting point.

Both residential and business customers can manage (add, update and remove) the authorizations in the Datahub authorization service or customer portal (as long as its authorization functionality is supported alongside). A customer can always terminate an authorization before the planned end date.

End customer authorization events

Open