SEPA Payment Suite provides internal data structures within the application in order to represent the hierarchical organization of the operating company. The definition of these structures is the responsibility of the client and is done directly through the application’s GUI. These data structures allow for the management of user authorizations in relation to the data handled by SEPA Payment Suite.
Two types of interconnecting structures are in place.
Distributing organization
A distributor is a commercial body that offers a mandate management service to one or several creditors.
A hierarchical structure in the form of a tree allows all existing varieties of organizational configuration to be represented: sub-contracting, break-down of supplier activity per region or according to commercial portfolios for example.
Picture 11: Distributing organization example
Each element of the tree, called a distributing organization entity, contains its own information (name, address, manager, etc.) and is responsible for a group of creditors that can be contacted from the platform’s GUI. A distributor entity can be linked to zero or several creditors.
It is possible to create, amend or delete a distributing organization entity. It is only possible to delete an entity if it has no sub-entities and is no longer linked to any creditors.
The distributor has an administrative function; in particular it is responsible for creating creditor organizations on the platform, allocating them the SCIs to use.
A distributing entity can view all SEPA flows and mandates managed by the creditors for which it is responsible. Root distributing entities have an aggregated view of the creditors managed by their child sub-distributing entities.
Distributors can subscribe to all or part of the catalogue of options offered by the software. They are then free to allocate or withdraw the options available to them to/from their sub-distributers, if any, so that they can manage their own catalogue of options or to/from their client companies so that they are able to benefit from the associated services within the software.
Company organization
As for distributors, creditors are represented in the form of a hierarchical structure in order to cover the different organizations that exist within a company.
Picture 12: Company organization example
One element of the creditor structure, called the company organization entity, is defined by name, a collection of SCIs, a collection of Business Codes and a collection of accounts (BIC and IBAN). These characteristics are spread from the top to the bottom of the structure and restrictions may be applied to each level of the organization.
A company organization must be linked to a distributor entity (see Distributing).
It is possible to create, amend or delete elements of a company organization. It is only possible to delete an element if the entity has no child entities and is not linked to any object (mandate, user, etc.).
The collection of SCIs, Business Codes and accounts associated with each entity determine which data (mandates, SEPA flows) it can access. For example, it is not possible to link a mandate to a given entity if it is not authorized for the SCI present in the mandate. If necessary, the application allows the company to define the SCI+Business Codes+accounts combinations authorized for this entity. By default, all SCIs, Business Codes and accounts combinations defined for this entity are authorized.
Rules of deduction can also be configured to allow automatic calculation
the account to be used according to the SCI and Business Code; or
the Business Code to be used according to the SCI and account.
These rules are applied during the mandate creation or direct debit request processes.
A company may be allocated options by its distributer; each of its entities therefore benefits from the services associated with these options within the software.
In addition, each company organization entity has a set of parameters that can be modified via the application GUI (see Appendix C – List of creditor parameters); the screens that allow for management of the UMR customization models and the configuration of notifications are accessible when viewing a company entity.
Unique Mandate Reference models
A Unique Mandate Reference model applies to both new mandates and migrated SEPA mandates. A model is characterized by:
-
A unique name to identify it within an organization creditor;
-
An optional description;
-
An ordered set of sub-fields that defines the structure of the model;
-
A length corresponding to the number of characters in the model (equivalent to the sum of the length of each sub-field) and to be less than or equal to 35.
A template is attached to a root creditor organization: a model defined on a given organization is usable on another entity of the same organization. A template is fully editable and can be deleted, except if it is a default model defined by SPS.
SEPA Payment Suite offers some default UMR models. The creditor can either choose a default template, or create a new one.
The following templates are automatically associated with any new organization creditor:
| Name | Description | Structure | Length |
|---|---|---|---|
| UIR only | Using the internal reference only present in the input stream | UIR | 35 |
| Free text + continuous sequence number | Concatenation of the prefix “REFERENCE MANDATES” followed by a continuous sequence number of 18 characters | Free text + continuous sequence number | 35 |
| Free text + current date + continuous sequence number | Concatenation of the prefix- “REFERENCE MANDATES” followed by the date in the format DDMMYYYY and terminated by a sequence number of 10 characters that is reset daily | Free text + current date + continuous sequence number | 35 |
| Free text + creditor country current date + sequence number daily | Concatenation of prefix characters “MANDATES REFERENCE” and creditor country code followed by the addition of the date (format DDMMYYYY) and terminated by a sequence number on 8 characters that is reset daily | Free text + creditor country current date + sequence number daily | 35 |
| Migration indicator + date + prefix + counter daily | Concatenation of the prefix “REFERENCE MANDATES “ followed by the date in the format DDMMYYYY and terminated by a sequence number of 8 characters that is reset daily. The set is preceded by two characters corresponding to the prefix is CFONB for mandates to be migrated French NW substitute for outstanding mandate migrated | CFONB prefix or substitute for mandates non migrated + free text + current date + sequence number daily | 35 |
If the creditor wants to create his own model, he can define it using some attributes. (See Appendix D - Attributes available to generate a UMR model).
Unique SDD Reference models
Configure a model
A Unique SDD Reference model applies to all the SDD whatever the creation
channel. A model is characterized by:
-
A unique name to identify it within an organization creditor;
-
An optional description;
-
An ordered set of sub-fields that defines the structure of the model;
-
A length corresponding to the number of characters in the model (equivalent to the sum of the length of each sub-field) and to be less than or equal to 35.
A template is attached to a root creditor organization: a model defined on a given organization is usable on another entity of the same organization. A template is fully editable and can be deleted, except if it is a default model defined by SPS.
SEPA Payment Suite offers some default SDD Reference models. The creditor can either choose a default template, or create a new one.
The following templates are automatically associated with any new organization creditor:
| Name | Description | Fields | Length |
|---|---|---|---|
| Free text + Continuous sequence number | Concatenation of prefix REF 3 characters followed by a continuous sequence number of 32 characters | Free text + Continuous sequence number | 35 |
| Free text +due date + Continuous sequence number | Concatenation of prefix REF 3 characters followed by the due date (6 characters) then a continuous sequence number of 26 characters | Free text +due date + Continuous sequence number | 35 |
| Original transaction identifier + creation date + Daily sequence number | Concatenation of the original transaction identifier (12 characters) followed by the current date (6 characters) then a daily sequence number of 17 characters | Original transaction identifier + creation date + Daily sequence number | 35 |
If the creditor wants to create his own model, he can define it using some attributes. (See Appendix E - Attributes available to generate a endToendId model).
Use the model
Transaction create from a payment schedule
The generation of transactions references is required in the case of a payment schedule creation. Therefore, authorization to generate a reference when creating a transaction from a schedule is not subject to a parameter defined at the node creditor.
If the payment schedule is variable, the creditor chooses at the schedule creation either to enter the reference for all transaction either to ask SPS to generate the transaction references. The model “Model to use for creation via payment schedule” will be used either it is a generic or a variable payment schedule.
Transaction create from WEB GUI
During the creation of a unitary transaction via WEB GUI, the creditor can choose:
-
To fill the reference in this case the endtoendId will be equal to the reference entry
-
To not fill the reference in this case the endtoendId will be generate thanks to the model “Model to use if no reference is provided”
Transaction create from a file
During the creation of a unitary transaction via file:
-
Either the reference is not provided:
-
If “model to use if no reference is provided” is defined, SPS will use this model to generate the end To end Id
-
If for the “model to use if no reference is provided” the choice “do not generated the end To end Id” is selected. SPS will reject the transaction
-
-
Either the reference is provided:
-
If “Model to use if a reference is provided” is defined, SPS will use this model to generate the end To end Id
-
If for the “Model to use if a reference is provided” the choice “Take the original reference as endToendId” is selected. SPS will copy the original reference in the end to end Id.
-