Overview
Under Bacstel-IP, rigorous payment file validation is an absolute requirement and has been introduced by the industry in order to reduce the number of rejected files and failed payments. Historically, Bacstel made a small number of structural checks upon receipt of submissions; these tests have been increased and strengthened under Bacstel-IP.
The required validation will be provided by the chosen Bacs approved Bacstel-IP solution. However careful consideration needs to be given to optimising the effectiveness of these validation processes and there are compelling reasons to consider the added value of also validating data within business applications.
Bactsel-IP validation requirements
Unlike Bacstel, Bacstel-IP requires that payment files are validated prior to submission.This includes checks for:
- the submission
- submission structure, in accordance with APACS standard 18
- duplicate submissions
- permitted characters (upper case letters (A-Z), numbers (0-9), full stop (.), ampersand (&), forward slash (/), dash (-) and space
- individual payment files
- filestructure, in accordance with APACS standard 18
- duplicate files
- processing date (a warning is produced if the date is incorrect; incorrect dates are overridden by Bacs to the current processing day)
- file balancing (the CONTRA records must match the payment instructions)
- currency code (GBP or € (GBP is the default)
- individual payment instructions
- periodic account limits (daily, weekly, monthly)
- payment instruction limits (total value of allowable credit/debit transactions that can be originated from an account over a specified timeframe; these are defined in the Bacs Service User Profile for the Bacs Service User Number)
- processing date
- transaction code (Direct Debit, Direct Credit, AUDDIS etc.)
- originating and destination sort code and account number
- format and transposition
- modulus check
- sort code open in Industry Sorting Code Directory (covers closed and redirected sort codes)
- transaction code supported
The stringent validation requirements of Bactsel-IP mean that more warnings and errors are produced by a Bacstel-IP solution than by a Bacstel solution. This in turn may cause delay, either as time is spent reviewing warnings, or because the file is rejected outright at the point of submission.
Errors and warnings
Improperly validated payment files submitted to Bacs will generate errors and warnings. To minimise these it is important to ensure that the root cause is addressed in the business application.
Errors
An error will prevent the user’s Bacstel-IP solution from submitting the payment file to Bacs or will cause the file to be rejected by Bacs. In addition to the reasons for rejection which exist currently under Bacstel, key additional checks introduced by Bacstel-IP are:
It is not possible to downgrade the severity of an error to a warning in order to force the submission through.
Warnings
Warnings reveal that problems exist in the payment file and that these require review. The receipt of a warning will not prevent submission, but will delay the process as the warnings are reviewed.
The cleaner the data is originally, the fewer warnings will be generated by the Bacstel-IP solution. This is important because a large volume of warnings may encourage users to accept each warning habitually with the risk that problems are missed, payments delayed and the whole purpose of validation - the improvement of data quality - is undermined.
If payment file submissions are automated using an HSM, validation in the business application becomes even more important.
Where should validation happen?
Where validation takes place has an important bearing on the number of warnings and errors that will arise and the time and cost involved in fixing them.
It is a requirement of Bacs that the Bacstel-IP solution validates the payment file prior to transmission. The Bacstel-IP solution may also validate the data during its import process, which may take place some time before transmission.
However, validation is safest, easiest and most efficiently fixed at the point of data entry into the business application, not within the Bacstel-IP solution. Although errors can be fixed in the Bacstel-IP solution, this causes a delay in submission and cannot be undertaken efficiently and effectively in a way that is auditable and traceable back into the business application. Validation in the business application is the most efficient and effective way to:
- virtually eliminate errors at submission time
- prevent delays at submission time
- prevent recurrence of the same error/warning
- ensure reconciliation between the business application and the transaction submitted to Bacstel-IP
- support Straight Through Processing (STP), the concept that a transfer is processed automatically end-to-end without manual intervention, from origination to the payee.
Even though the point of data entry is the most important stage at which to validate account details in the business application, validation rules may change over time. The most effective way to deal with this eventuality is to periodically review the account details in the database and to revalidate once more before export to the Bacstel-IP solution. This gives the user a head-start in preventing errors and warnings before they become a problem.
Selecting validation software
Regular validation of the data at the point of data entry, periodic review and revalidation prior to export from the business application (as well as in the Bacstel-IP solution) is the only way to maximise the opportunity to achieve STP of Bacs payment submissions. In addition, fixing problems in the business application preserves the auditability and traceability of all the data in the business application.
In selecting a validation solution it is essential to consider:
- the regularity with which reference data is published
- the ease with which it is integrated into the business applications
- whether it will run on all the user’s operating systems
- whether the supplier uses all possible data sources (published and unpublished)
It is also important to establish how much validation is carried out beyond the minimum Bacs validation requirements using the Industry Sorting Code Directory, modulus check and transposition algorithms published by Bacs. Finally, organisations should also establish the regularity with which the data is updated to ensure they are always using the most up-to-date information available.
01/01/06
