[EP] Settlement

[DuneSe]

Question: Will settlement related information be eventually modelled in FlexOffer or is it considered out of scope? By: Isidoros Kokos, Intracom

[DuneSe]

Includes EPs #5 and #21

[cerne739]

Financial settlement is implemented in the FO protocol within FEVER project. It supports virtual currency and consists of the three steps: 1) get account info 2) fund reservation and 3) settlement. The feature was implemented via external P2P service provider and requires some additional parameters

[DuneSe]

Zoran:

In discusion about settlement and its relation to FO, there are the following important aspects to consider:

Settlement is a business transaction
Settlement is a process defined within HEMRM (ebIX view) in the chain of processes (structure, plan, trade, operate, measure, settle, bill)
In automated trading of flexibilities, we perform online micro-contracts (agree, schedule, confirm), which are nested into an implied framework business contract, extending over longer period (months, years). This framework contract is not automated and it is a business process. The contract defines the actual payment period (typically per month, if this is a service contract)

Current SOTA is that the business processes in a legal entity are monitored and registered by an ERP software system. In order to transfer the micro-settlements into business transaction, there has to be established a link between out automated trading platforms and the ERP systems. We have opened this discussion already in GOFLEX. In FEVER, within HLUC 15 (WP5), the issues were identified further but with IBM we established we did not have a genuine stakeholder in the project on the business side – an ERP provider partner. The settlement case that was carried out was done within the intra-LEC P2P trading system, which main focus was to tackle the challenge of multi-category trading (with pseudo currency and pseudo coin as the instrument) and the settlement was carried out within this virtual ecosystem, without linking it to the ERPs of the actual business entities involved .

We think the approach we should take is to develop a generic interface between the automated trading platforms and the ERPs (could be termed “Settlement agent” or “ERP coupling agent” or maybe “ERP Connector”), somewhat similar to the interface between the automated trading platforms and xEMSs (termed “Trading agent”); and the specific (or extended) FlexOffer protocol to cover it. This is “long overdue” and we think our UG should support it within the scope of our possibilities. By the way, the cross-sector coupling deals (has to deal) with one of the issues in the ERP coupling: different time constants of processes.

However, the task is more complex:

On the side of the business transactions, there is a number of country-specific regulatory constrains that cannot be standardised on European kevel (e.g., against P2P trading between prosumers). Even more so because regulatory environment is evolving. Consequently, the approach to take is to structure the ERP coupling agent into two segments: on the flex trading side have generic FO protocol (FO Settlement agent), while on the business settlement side a set of specific billable instructions (Business settlement algorithm), adapted to regulatory constraints. This could maybe be capped towards ERP with a thin ERP socket that could again be generic, following international accounting standards.

This is a developmental project with ERP developer partner on board and with demo cases in several countries. And to note: with the ERP “connection” we are stepping out of the sandbox environment.