General
Depending on the status of the mandate, only a portion of its data can be modified on SEPA Payment Suite (see Modifiable Data). However, updating particular data is considered an amendment (within the EPC meaning) of the mandate. SEPA Payment Suite reflects the changes made to the mandate during the generation of the next debit. The amendment flag is positioned in the debit when necessary.
The following reasons are considered amendments recognized by the EPC:
-
The creditor defines a new unique mandate reference (UMR),
-
The creditor has a new SEPA identifier (SCI),
-
The creditor’s name has changed,
-
The debtor indicates a different account to debit in the same bank,
-
The debtor indicates a different account to debit at another bank.
Supporting documentation can be attached for each modification.
Each modification of a mandate results in the generation of an audit trail by SEPA Payment Suite, including the date/time of the amendment coming online, the origin of the modification (filename, query identifier or user login), the modified data and its value before modification.
The exchange methods supported for this operation are presented in this table.
The following schema shows the amendment management:
Figure 4.10.1 Amendment management
Modifiable Data
The following table shows the mandate data that can be modified, based on its status:
Data | Pending | Sent to the debtor | Waiting validation/ Waiting for reachability | Suspended | Active |
---|---|---|---|---|---|
UMR | X | X | X | X | |
UIR | X | X | X | X | |
Creation mode | X | ||||
Type of mandate | X | X | |||
Payment type | X | ||||
Date of signature | X | X | |||
Town/city of signature | X | X | |||
SCI | X | X | X | X | |
Creditor’s bank (BIC) | X | X | X | X | |
Creditor’s IBAN | X | X | X | X | |
Debtor’s name | X | X | X | X | X |
Debtor’s bank (BIC) | X | X | X | X | X |
Debtor’s IBAN | X | X | X | X | X |
Debtor’s address | X | X | X | X | X |
Debtor’s country of residence | X | X | X | X | X |
Debtor’s e-mail address | X | X | X | X | X |
Debtor’s telephone number | X | X | X | X | X |
Debtor’s identification code | X | X | X | X | X |
Name of third party debtor | X | X | X | X | X |
Third party debtor identification code | X | X | X | X | X |
Name of third party creditor | X | X | X | X | |
Identification code of third party creditor | X | X | X | X |
For others statuses: Obsolete, Cancelled and Finalized no modification is authorized.
Modifying the debtor account
If the user is not associated with the âView Beneficiary IBAN dataâ profile, the debtor account for the mandate cannot be updated as described in following paragraphs:
- If the account is displayed as a text field. (the âUse of BBANâ option is also disable)
Figure 4.10.2.1.1 - a non-editable debtor account text
- If the third party database is activated then the âNew accountâ option is not available in the debtor account dropdown. However, user can select any other option from the dropdown and update the same for the mandate.
Figure 4.10.2.1.2 - editable debtor account dropdown
Processing modification requests
Identifying the mandate based on requests informationâs
Upon receipt of a modification request, SEPA Payment Suite identifies the mandate to change from the UMR or UIR present in the request.
If the UMR is provided, then a simple search is done in SPS database and if a mandate is found (at most one mandate can be found starting from the UMR) then this one will be considered for the modification.
If the UIR is provided on the request, then several cases may occur:
-
No mandate already exists for this UIR and the corresponding organization - > in this case the modification cannot be executed.
-
An unique mandate uses this UIR â in this case this one will be the mandate to be modified
-
In the case when multiple mandates correspond to the same UIR for a particular organization:
-
The mandate that will be considered for being modified will be the Active one.
-
If no Active mandate exists among the list of mandates with the same UIR, but a single one is in Pending status, then this one will be considered for being modified.
-
In all the other cases as no mandate could be clearly identified, the modification cannot occur.
-
Executing the modifications
SEPA Payment Suite checks:
-
the mandate status: only mandates with “Pending”, “Sent to debtor”, âWaiting for validationâ, âWaiting for reachabilityâ, “Suspended” or “Active” statuses can be modified;
-
Format and consistency of new data.
Once the mandate is Active, it is impossible to delete mandatory information, the creditor user can only update it.
If the UMR, the SCI or the name of the creditor, the account or the BIC of the debtor are modified, the next SDD relating to this mandate will contain the updated information and will be flagged as amended.
The mandate status is updated or remains unchanged, as appropriate. The audit trail is automatically updated: it specifies the timestamp and the source (filename, query identifier or user login) of the change.
If there are SDDs relating to a mandate changing its status, their status is also updated (see SDD status management).
Whatever the result of processing, SEPA Payment Suite generates a response to the request in accordance with its mode. The reasons for inclusion or rejection are:
-
Modification accepted,
-
No associated mandate,
-
The status of the mandate does not allow modification,
-
The debtor’s bank details are incorrect.
Modification of a mandate with future plan date
SPS allows to the user to decide when the update will take place, the future modification depend on the Plan Date provided by the user in the update request.
Via GUI, on the modification page, if you want to determine a date for the update, you have to click on the button âplanned modificationâ. A popup requesting the user to enter the Plan Date is displayed. A validation is done if the Plan Date is entered and valid. A valid Plan Date is a date that is greater than todayâs. This means the Plan Date cannot be in the past, or be the present date.
A planned modification can be launched by Web service or by file (csv/xml).
After each planned modification, a processing a report is created. It can be downloaded via the File Search page.
The planned modifications are displayed in descending order of plan date. All the planned modifications are displayed by comparing its changes with latest planned modification that occurs before the given planned modification date instead of comparing with current mandate status.
For example, if there are 3 planned modifications which are planned on 3 different days, then following will be the entries under planned modification tab.
Current values: Mandate name: XYZ
When user enter 1st planned modification: new value for debtor name: XYZ001 planned for date1, following result is expected
Modified attribute | Original value | New value | Future Plan Date | Status |
---|---|---|---|---|
Debtor name | XYZ | XYZ001 | Date1 | PLANNED |
When user enter 2nd planned modification: new value for debtor name: XYZ002 planned for date2 where date2<date1, following result is expected
Modified attribute | Original value | New value | Future Plan Date | Status |
---|---|---|---|---|
Debtor name | XYZ002 | XYZ001 | Date1 | PLANNED |
Debtor name | XYZ | XYZ002 | Date2 | PLANNED |
When user enter 3rd planned modification: new value for debtor name: XYZ003 planned for date3 where date2<date3<date1, following result is expected
Modified attribute | Original value | New value | Future Plan Date | Status |
---|---|---|---|---|
Debtor name | XYZ003 | XYZ001 | Date1 | PLANNED |
Debtor name | XYZ002 | XYZ003 | Date3 | PLANNED |
Debtor name | XYZ | XYZ002 | Date2 | PLANNED |
Modification of a mandate with a wrong Debtor account
When modifying a mandate, if the option âAuthorize the creation of mandates with an incorrect Debtor accountâ is activated for the Organization, the user can fill a wrong Debtor account. The mandate will be edited and set to pending status. A warning message is displayed on top of the page to inform him that the mandate status became pending and the erroneous Debtor account is displayed in RED.
Modification of mandate with Debtor manager
While modifying a mandate, if the third party database is activated on the organization, following are the cases that can occur:
-
If the mandate is linked to a debtor of the third party database and if the user tries to add a new account then that account will be saved and added to third party.
-
If the external id is set for the mandate and if that external id is present in third party database then all debtor data already set for that mandate will be replaced by the third partyâs data related to the external id.
-
If the external id is set for the mandate and if it is not present in third party database then it will be saved on that mandate, but it will not be added to the third party database.
Modification of Mandate with Fraud Control Check
SPS allows modifying mandates with a fraud control check. If the SPS Fraud option and fraud profile is active on the organization then only modifying mandate comes under the Fraud Control check. When modifying the mandate if the Fraud Configuration for the web is activated and fraud decision is Red then it blocks the modifying of the mandate and displays the error message. But if Fraud Configuration for the web is deactivated and fraud decision is red then it allows the modifying of mandate and display a warning message only.