Validations
Validation API
SEPA CT 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 Clearing and Settlement.
The response from the service will be a canonical pacs.002 with the status of the validations. It can also include an xml scheme version of the submitted pacs.008 if the 'returnEBASchemeMessage' flag is set to True.
Validate EBA Scheme Rules
The endpoint for Validate EBA Scheme 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 (or equivalent, e.g. Assignment for camt.056) 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 EBA Scheme format message
-
Individual Transaction Validations (or equivalent, e.g. TxInfAndSts for camt.029) and Scheme Rule Validations
-
EBA Schema Check of the final validations
The Validations API can return the EBA Scheme format message in the response if requested in the "Validate EBA Scheme Rules" request. The transactions that fail the validations will be removed from the EBA format message so the output EBA 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 scheme 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
The duplicate checks are not performed on the validation API call. This is 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 keeping in mind that the submission to validation API is not same as request to clear and settle and that the dates on the transactions may be updated when they are finally submitted for clearing.
A separate endpoint has been created to validate interbank settlement dates independently, ensuring that the date validation aspect is addressed.
See the Validation API Swagger Specification here Validation API
Request Processing API
SEPA CT STEP2 CSM Service supports below validations on the 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 individual features to understand applicable validations).
The scheme rules are identified and referenced from scheme documentation (STEP2 SCT Interface Specifications, STEP2 SCT Functional Description).
All message types will have a schema check performed using the current version of the 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 (eg settlement date is no more than three working days in advance, any ISO codes are valid for the particular use or calculated totals are equal to the counts they relate to).
Messages arriving from the scheme will receive a technical check against their xsd. The only Business level validations to take place will make sure they are;
-
not duplicates (file or individual transactions),
-
intended for the Direct Participant running the instance of SEPA CT CSM and their configured Regional Brands,
-
containing address formats that have been correctly used (either structured, unstructured or scheme allowed combinations of the two).
Inbound messages from the scheme that fail validations, 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 CT scheme pack does not have a mechanism for the automated rejection of an inbound message.
Validations Rules
Debtor CT (pacs.008 Bulks)
Message / Bulk Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Message Duplicate Check |
|
|
The following fields are checked for duplicate:
(B14) |
Group Header Totals Validation |
|
|
|
Interbank Settlement Date Validation |
|
|
|
Group Header Clearing System and Instructing Agent Validation |
|
|
|
Transaction Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Transaction Duplicate Check |
|
|
The following fields are checked for duplicate:
|
Service Level Check |
|
|
CdtTrfTxInf.PmtTpInf.SvcLvl.Cd should contain 'SEPA' (IN02) |
Category Purpose Code Check |
|
|
If CdtTrfTxInf.PmtTpInf.CtgyPurp.Cd is one of FCIN, FCOL, or INTE and:
|
Debtor & Creditor Names Check |
|
|
If the category purpose code is one of FCIN, FCOL, or INTE and if:
|
Postal Address Check |
|
|
|
Country Codes Check |
|
|
|
Instructing Agent Check |
|
|
|
End To End Id Check |
|
|
|
Debtor/Creditor Agent SEPA COM Pacifique Check |
|
|
|
Remittance Information Check |
|
|
|
Creditor CT (pacs.004 Bulks)
Message / Bulk Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Message Duplicate Check |
|
|
The following fields are checked for duplicate:
(B14) |
Group Header Totals Validation |
|
|
|
Group Header Clearing System and Instructing Agent Validation |
|
|
|
Interbank Settlement Date Validation |
|
|
|
Transaction Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Transaction Duplicate Check |
|
|
The following fields are checked for duplicate:
|
Service Level Check |
|
|
TxInf.OrgnlTxRef.PmtTpInf.SvcLvl.Cd should contain 'SEPA' (IN02) |
Return Reason Info Reason Code Check |
|
|
|
Country Codes Check |
|
|
|
Additional Information Check |
|
|
If TxInf.RtrRsnInf.Rsn.Cd contains 'FOCR' and if TxInf.RtrRsnInf.AddtlInf is populated (XT33) |
Debtor CT (pacs.004 Bulks)
Returns of a previously sent pacs.008 cannot be rejected. If they were, there would be no legitimate account for the funds to be credited to. A bank receiving a pacs.004 has to process it in some way (by crediting the originator of the pacs.008 or a suspense account pending investigation).
For this reason, only the following checks are performed:
Creditor CT (camt.029 Bulks)
Message / Bulk Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Message Duplicate Check |
|
|
The following fields are checked for duplicate:
(B14) |
Instructing Agent BICS check |
|
|
|
Status Confirmation Check |
|
|
If ResolutionOfInvestigation.Sts.Conf is not one of the valid statuses (XT33):
|
Transaction Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Transaction Duplicate Check |
|
|
The following fields are checked for duplicate:
|
Cancellation Status Reason Info Code Check |
|
|
If TxInfAndSts.CxlStsRsnInf.Rsn.Cd is not one of the valid codes (XT33):
|
Original Message Name Id Check |
|
|
If TxInfAndSts.OrgnlGrpInf.OrgnlMsgNmId is not one of either pacs.008.001.08 or pacs.008.001.02 (XT33): |
Claim For None Receipt Fields Check For IQF Camt.029 |
|
|
|
Clearing System Check For IQF Camt.029 |
|
|
|
Country Codes Check |
|
|
|
Resolution Related Information Check For IQF Camt.029 |
|
|
|
Status Confirmation Field Check For IQF Camt.029 |
|
|
|
Debtor CT (camt.056 Bulks)
Message / Bulk Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Message Duplicate Check |
|
|
The following fields are checked for duplicate:
(B14) |
Total Number Of Transactions Check |
|
|
|
Instructing Agent BICS Check |
|
|
|
Transaction Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Transaction Duplicate Check |
|
|
The following fields are checked for duplicate:
|
Original Message Name Id Check |
|
|
|
Cancellation Reason Info Reason Code Check |
|
|
|
Debtor CT (pacs.028 Bulks)
Message / Bulk Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Message Duplicate Check |
|
|
(B14)
|
Instructing Agent BICS Check |
|
|
If PaymentStatusRequest.GrpHdr.InstgAgt.FinInstnId.BICFI is null/empty or branch code is included (B10) |
Transaction Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Transaction Duplicate Check |
|
|
|
Country Codes Check |
|
|
|
Category Purpose Code Check |
|
|
If TxInf.OrgnlTxRef.PmtTpInf.CtgyPurp.Cd is one of FCIN, FCOL, or INTE and:
|
Original Group Information Check |
|
|
|
Original Message Name Id Check |
|
|
|
Clearing System Check |
|
|
If FIToFIPmtStsReq.TxInf.OrgnlTxRef.SttlmInf.ClrSys.Prtry is not set to ST2 (B16) |
Service Code Check |
|
|
If FIToFIPmtStsReq.TxInf.OrgnlTxRef.PmtTpInf.SvcLvl.Cd is not SEPA (XT33) |
Remittance Information Check |
|
|
If FIToFIPmtStsReq.TxInf.OrgnlTxRef.PmtTpInf.LclInstrm.Cd is set to PERI and FIToFIPmtStsReq.TxInf.OrgnlTxRef.RmtInf.Strd is populated (XT13) |