Validations
Validation API
SEPA DD STEP2 CSM Service provides a Validation API to enable the Client Implementation flows or SDK clients to submit the bulks for validation purposes only. The request to the API does not lead to the bulks being submitted for Collecting and Settlement.
The response from the Direct Debit Validation API is Direct Debit Validation API which can comprise a message level OrgnlGrpInfAndSts block, transaction level TxInfAndSts block(s) and (if requested) a schemeFormatMessage block.
Validate Direct Debit Scheme Rules
The Direct Debit Scheme Rules API rule carries out the validations on the submitted bulks and included transactions and provides a validation response. Below validations are performed:
-
Message Level Validation (Bulk level validations)
-
Validation of Group Header totals such as Count of transactions and Interbank Settlement Amounts.
-
Scheme Rules Validations against the Header fields
-
-
Mapping from the IPF Canonical format message to the Scheme format message
-
Individual Transaction Validations and Scheme Rule Validations
-
Schema Check of the final validations
The Validations API can return the Scheme format message in the response if requested in the request if the 'returnSchemeMessage' flag is set to True. The transactions that fail the validations will be removed from the format message so the output scheme format message will always be acceptable by the scheme. When removing the failed transactions, the CSM service will adjust the group header totals (count of transactions and amounts), so they match the transactions that have passed validations. The SEPA DD CSM Service does not alter the contents of individual transactions in any shape or form so the transactions transparency is always maintained.
Please note that below validations are not performed when the bulks are submitted to the Validation API.
-
Duplicate check on the submitted bulks
-
Duplicate check at transaction level
-
Validations against the settlement dates submitted on the bulks
Duplicate checks are not performed on Validation API calls, to ensure the same bulk can be submitted multiple times for validation without being rejected as duplicate in later attempts or when it is eventually submitted for clearing and settlement.
Interbank Settlement Date Validations are not performed on Validation API calls as these dates may be updated when submitting to the Direct Debit API for clearing.
See the validation specification here Direct Debit Validation API
Request Processing API
SEPA DD STEP2 CSM Service supports below validations on bulks submitted from Client implementation flows. It is important to note that some validations may not be applicable based on the source of request. (Refer to individual features to understand applicable validations).
The scheme rules are identified and referenced from scheme documentation (STEP2 SDD Interface Specifications, STEP2 SDD Functional Description).
All message types will have a schema check performed using the current version of the scheme xsd. This action will perform all the necessary technical checks on the message such as data types, cardinality and size of data elements. As well as these Technical checks, the SEPA CSM performs Business-level checks, to ensure the data input to each field conforms to any rules over and above the basic Technical checks (e.g. settlement date is no more than 14 working days in advance, any ISO codes are valid for the particular use or calculated totals are equal to the counts they relate to).
Inbound Messages
Messages arriving from the scheme will receive a technical check against their XSD. This applies to all supported message types which arrive into Debulker from SEPA STEP2 in the following files:
-
DVF
-
RSF
The business level validations are documented in the inbound message tables below.
Inbound messages from the scheme that fail validation will still be passed to the client, however they will be added to a dedicated Kafka topic that should be routed to an exception processing implementation. The SEPA DD scheme pack does not have a mechanism for the automated rejection of an inbound message.
Validation Rules
Collect and Settle (Pacs.003)
Message Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Canonical Model Validation |
|
|
Validation against the canonical model before mapping (FF01) |
Message Duplicate Check |
|
|
The following fields are referenced as part of the duplicate check:
(B14) |
Interbank Settlement Date |
|
|
|
Scheme XSD Validation |
|
|
Schema validation against the scheme XSD after mapping (FF01) |
Group Header Totals Validation |
|
|
|
Group Header Clearing System and Instructing Agent Validation |
|
|
|
Transactions Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Transaction Duplicate Check |
|
|
The following fields are checked for duplicate:
(AM05) |
Service Level Checks |
|
|
DrctDbtTxInf.PmtTpInf.SvcLvl.Cd should contain 'SEPA' (XT33) |
Local Instrument Checks |
|
|
DrctDbtTxInf.PmtTpInf.LclInstrm.Cd should contain 'CORE' (XT33) |
Debtor/Creditor Agent SEPA COM Pacifique Check |
|
|
|
Instructing Agent Check |
|
|
DrctDbtTxInf.InstgAgt.FinInstnId.BICFI should not be populated (XT13) |
Requested Collection Date Check |
|
|
|
Postal Address Country Code Check |
|
|
|
EEA Country Codes Check |
|
|
Debtor Postal Address Country is mandatory if Debtor Agent and/or Creditor Agent are not in the EEA. Note - this validation is disabled by default - see configurations page
|
Postal Address Structural Check |
|
|
Addresses are classified according to the address fields populated as per Appendix A: Postal Address Structural Validations
Note - these validations are disabled by default - see configurations page. |
Creditor Scheme Id and Name Check |
|
|
|
Mandate Amendments |
|
|
|
Party Name Length Check |
|
|
|
Structured Remittance Information Length Check |
|
|
DrctDbtTxInf.RmtInf.Strd must not exceed 140 characters (where the number of characters is counted between the Structured tags, not inclusive) (XT33) |
Only one occurrence of DrctDbtTxInf.RmtInf is allowed |
|
|
DrctDbtTxInf.RmtInf must not contain more than 1 occurrence of structured remittance information and must not contain more than 1 occurrence of unstructured remittance information. The STEP2 SDD data model allows up to 10 occurrences, but an additional usage rule specifies that only 1 occurrence of each type is allowed (XT13) |
Cancellation (Camt.056)
Message Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Canonical Model Validation |
|
|
Validation against the canonical model before mapping (FF01) |
Scheme XSD Validation |
|
|
Schema validation against the scheme XSD after mapping (FF01) |
Message Duplicate Check |
|
|
The following fields are referenced as part of the duplicate check:
(B14) |
Assigner Agent Validation |
|
|
Assgnmt.Assgnr.Agt.FinInstnId.BICFI length is bigger than 8 (B12) |
Total Number Of Transactions Validation |
|
|
CtrlData.NbOfTxs is not equal to the number of transactions in the bulk (B03) |
Transaction Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Transaction Duplicate Check |
|
|
The following fields are checked for duplicate:
(AM05) |
Original Message Name ID Validation |
|
|
If Undrlyg.TxInf.OrgnlGrpInf.OrgnlMsgNmId does not start with pacs.003 (XT33) |
Original UETR Validation |
|
|
If Undrlyg.TxInf.OrgnlUETR is present (XT81) |
Assigner Agent Validation |
|
|
If Undrlyg.TxInf.Assgnr.FinInstnId.BICFI is present (XT13) |
Original Interbank Settlement Date |
|
|
|
Reversal (Pacs.007)
Message Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Canonical Model Validation |
|
|
Validation against the canonical model before mapping (FF01) |
Interbank Settlement Date |
|
|
GrpHdr.IntrBkSttlmDt is not the Current Interbank Settlement Date (B15) |
Scheme XSD Validation |
|
|
Schema validation against the scheme XSD after mapping (FF01) |
Message Duplicate Check |
|
|
The following fields are referenced as part of the duplicate check:
(B14) |
Group Header Totals Validation |
|
|
|
Group Header Clearing System and Instructing Agent Validation |
|
|
|
Original Message Name ID Validation |
|
|
If OrgnlGrpInf.orgnlMsgNmId does not start with pacs.003 (XT33) |
Transaction Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Transaction Duplicate Check |
|
|
The following fields are checked for duplicate:
(AM05) |
Reversal Reason Code Check |
|
|
If TxInf.RvslRsnInf.Rsn.Cd is not one of AM05, MS02 or MS03 (XT33) |
Original Interbank Settlement Date |
|
|
|
Transaction Instructing Agent Check |
|
|
If TxInf.InstgAgt.finInstnId.bicfi is present (XT13) |
Transaction Reversed Instructed Amount Check |
|
|
|
Transaction Reversed Interbank Settlement Amount Check |
|
|
If TxInf.RvsdIntrBkSttlmAmt is not equal to TxInf.OrgnlIntrBkSttlmAmt plus TxInf.ChrgsInf.Amt (XT78) |
Inbound pacs.002
The following validations are performed on an inbound pacs.002 from the scheme.
Appendix A: Postal Address Structural Validations
| Address Line Populated | Town Name Populated | Country Populated | Any Other Address Fields Populated | Classification |
|---|---|---|---|---|
No |
Yes |
Yes |
– |
Structured |
Yes |
No |
Yes |
No |
Unstructured |
Yes |
No |
No |
No |
Unstructured |
Yes |
Yes |
Yes |
– |
Hybrid |
If configured, transactions that cannot be classified as one of the above address types will result in a validation failure