The EBICS specification regulates the type and process of authorisation for payment submissions. For this purpose, various parameters are specified that allow different authorisation models to be defined.
But is all this enough to comprehensively cover market requirements? Apparently not, because only recently, with EBICS 3.0.2, the optionally usable complementary signature classes X and Y were specified for a new authorisation model. This extension comes with new EBICS schemes. Do new wishes and requirements in this field necessarily have to be accompanied by changes to the EBICS specification?
Not really, because there is another way. As is known, the basic structure in EBICS is formed by the signature classes T, E, A and B with different values and the option of choosing the number of required electronic signatures. In combination with signature class T, authorisations can even be instructed outside EBICS. With the electronic distributed signature (EDS) functions, it is also possible to decouple transport and authorisation.
The basic construction kit for extended authorisation models in EBICS is thus available.
Very diverse and heterogeneous requirements
For example, the German Banking Industry Committee (DK) has specified a special form of an authorisation model with existing EBICS means for the use of the SDC procedure under EBICS. This takes into account the separation of transfers by a service provider and authorisation by the original customer using the existing EBICS options; there is another use case with the trustee model. In addition, there are always market requirements which can certainly be mapped without adjustments to the EBICS protocol. Such requirements concern, for example, authorisation sequences and the delegation of authorisations, but also authorisations in group assignments. These models can generally be implemented with existing EBICS means on the bank server or in the customer client.
Precisely because the variety of requirements is potentially large and in part very individual, and in order to avoid compatibility problems, it makes sense to implement these concepts outside the EBICS specification where possible.
The solution to all problems
A versatile solution model is the group concept. EBICS users are divided into any groups on the bank server. The groups can also be customer-specific. The business transactions, signature classes and number of signature classes apply unchanged. For authorisation, it can be selected whether the final authorisation should only be carried out with users from different groups or only from one common group when using the concept. A group sequence for visibilities in the EDS query is also possible. The configured model can then be documented for the customer in the BPD sheet. This way, many authorisation models can be defined in an EBICS version-compatible and interoperable manner, including the complementary signature model. How about that?
Author: Michael Lembcke
0 comments:
Post a Comment