Does it have to be like that? How about granting the first registered EBICS user, let's call them User 0, the right to create further EBICS users – and to authenticate them immediately? What would that look like?
Let us imagine a new administrative EBICS order type to which we give the exemplary name HUC (EBICS User Create). HUC would be an upload; the included EBICS message would contain the necessary master data of the new EBICS user as well as that user’s three certificates. The message is signed by User 0. With the data and the signature, the EBICS server can immediately set up the user; INI and HIA orders, letters and waiting times are eliminated. We get another ready-to-go user without any initialisation hassle. There are signs of a customer-side need for such an "EBICS self-service": after all, efforts are being made with EBAM to promote a very similar service for accounts.
If it were that simple, we would probably have done it already. However, one is immediately faced with two questions:
1. How do we control such a powerful EBICS user as User 0?
2. What kind of master data is actually necessary?
The first question is surprisingly easy to answer: because if there is one thing EBICS is really good at, it is checking authorisations. In order to prevent an overly powerful User 0, a User 1 is set up at the very beginning and it is specified that a HUC order requires several signatures. Thus a four-eyes principle is in place and the familiar mechanisms of E, A and B signatures enable a very precise configuration of who can set up additional employees along with whom.
The much more difficult question is: what kind of master data is required? Most people will agree that a name is probably necessary, but after that it becomes tricky. Do we want to know the address, telephone number and e-mail address of the user? Are they perhaps even mandatory? Or is it better not to burden oneself with unnecessary personal data considering the GDPR? So far, every financial institution can decide for itself, but HUC would set a standard for everyone. And nobody is helped if a standard essentially consists of a vast number of optional fields. The financial institutions would be called upon to agree on a meaningful set of binding data.
The difficulty of this can be seen in EBICS itself – with the order types HKD and HDT. Designed to enable a customer system to obtain information on the customer, the associated EBICS users and their authorisations from the financial institution, these two order types lead a rather shadowy existence as it was not possible to reconcile the historically developed authorisation models of the various financial institutions. On the contrary, many financial institutions see their special degrees of freedom in the allocation of rights as a unique selling point. This is not compatible with standardisation.
Therefore it seems that the inconsistent rights models mean the premature and certain death of an EBICS self-service. However, it really only seems that way. In reality, a financial institution needs the many ways of assigning rights to do justice to all its customers; the individual customer does not tend to need them or at least not all at once: how many roles are there for a typical corporate customer anyway? There are those who may submit orders but are not allowed to authorise them, those with limited or extensive signing authority for this or that account, and then there are those who may set up new EBICS users. All in all, about a handful of roles which are created at the same time as the EBICS agreement is set up and which can be used to play around with the full range of the financial institution's authorisation configuration. The role is then given a name which the customer can use (e.g. authorised signatory) and which can then be easily specified in the HUC request for the new authorised signatory.
Such a role model has even more advantages. It is possible to adapt the role to the new conditions of the company (an account has been added) without having to look at the authorisations of all EBICS users. The roles can also be reassigned. And it is easier to get an overview of who actually has which role and therefore which authorisation.
While the definition of the roles will inevitably remain a manual task, the assignment of the roles can be carried out in the EBICS self-service. Aside from creation, the service would then still be missing the possibility to read, update and delete the EBICS user, i.e. the R, the U and the D from CRUD. The corresponding order types could be called HUR, HUU and HUD. That would make for a nice first draft for the EBICS self-service.
And all the initialisation troubles would almost completely disappear into thin air.
Author: Curd Reinert
