Validations
Validation API
SEPA CT STEP2 CSM Service provides a Validation API that enables IPF flows to submit bulks for validation purposes only. The request to the API does not lead to bulks being submitted for Clearing and Settlement.
The response from the service is a canonical pacs.002 with the status of the validations. It can also include a scheme format XML version of the 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 the 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 Clear And Settle API 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
The SEPA CT STEP2 CSM Service supports the below validations on bulks submitted from 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 the 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 (e.g. 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).
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:
-
SCF
-
OQF
-
CVF
-
RSF
-
PCF
-
QVF
The business level validations are documented in the inbound message tables below.
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
Outbound pacs.008
Message / Bulk Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Message Duplicate Check |
|
|
The following fields are referenced as part of the duplicate check:
(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:
|
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 can be disabled - see configurations page
|
Postal Address Structural Check |
|
|
Addresses are classified according to the address fields populated as per the Postal Address Structural Validations
Note - these validations can be disabled - see configurations page. |
Country Codes Check |
|
|
|
Instructing Agent Check |
|
|
|
End To End ID Check |
|
|
|
Debtor/Creditor Agent SEPA COM Pacifique Check |
|
|
|
Remittance Information Check |
|
|
|
Inbound pacs.008
The following validations are performed on an inbound pacs.008 from the scheme.
| Rule | Description |
|---|---|
Functional Duplicate Check |
The following fields are checked for duplicates:
|
Creditor Agent Validation |
Checks if the following BICs match and are valid direct/indirect participants:
|
Postal Address Structural Check |
Addresses are classified according to the address fields populated as per the Postal Address Structural Validations
Note - these validations can be disabled - see configurations page. |
Outbound pacs.004
Message / Bulk Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
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 |
|
|
|
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) |
Inbound pacs.004
The following validations are performed on an inbound pacs.004 from the scheme.
| Rule | Description |
|---|---|
Functional Duplicate Check |
The following fields are checked for duplicates:
|
Debtor Agent Validation |
Checks if the following BICs match and are valid direct/indirect participants:
|
Outbound camt.029
Message / Bulk Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Message Duplicate Check |
|
|
The following fields are referenced as part of the duplicate check:
(B14) |
Instructing Agent BICS check |
|
|
|
Status Confirmation Check |
|
|
If ResolutionOfInvestigation.Sts.Conf is not one of the valid statuses (XT33):
|
Field Presence Check |
|
|
If required fields are not present based on message type and status (XT13):
|
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 does not start with pacs.008 (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 |
|
|
|
Inbound camt.029
The following validations are performed on an Inbound camt.029 from the Scheme.
| Rule | Description |
|---|---|
Debtor Agent Validation |
Checks if the following BICs match and are valid direct/indirect participants:
|
Outbound camt.056
Message / Bulk Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Message Duplicate Check |
|
|
The following fields are referenced as part of the duplicate check:
(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 |
|
|
|
Inbound camt.056
The following validations are performed on an Inbound camt.056 from the Scheme.
| Rule | Description |
|---|---|
Creditor Agent Validation |
Checks if the following BICs match and are valid direct/indirect participants:
|
Outbound pacs.028
Message / Bulk Level Rules
| Rule | Request Processing API | Validation API | Description |
|---|---|---|---|
Message Duplicate Check |
|
|
The following fields are referenced as part of the duplicate check:
(B14)
|
Instructing Agent BICS Check |
|
|
If PaymentStatusRequest.GrpHdr.InstgAgt.FinInstnId.BICFI is null/empty or branch code is included (B10) |
Multiple Transaction Check |
|
|
If the message contains more than one transaction (B02) |
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) |
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