BACS Pre-Submission Validation

Purpose

When building an automated BACS submission workflow, this node is responsible for checking the transactions in the submission by validating them against BACS or Faster Payment scheme rules and other Paygate security rules.

The way Paygate processes a workflow with a BACS Pre-Submission Validation node is illustrated below:

• A trigger fires and start the workflow running
• A Mapping will take a payment file and read it into the Paygate system ready for processing. The Pre-Submission Validation node sets the submission reference and (optionally) the contra narrative.
• The node will then run through dozens of test in which the data in the payment file is checked. This failing the test with an error status are removed from the submission because error such as these will cause the BACS to fail the submission to BACS if attempted.
• Optionally you can also remove less serious issues, found by the validation process, that have been flagged as warnings. Duplicate transactions can also be optionally automatically removed fom the submission.
• Those items removed from the submission can be saved to a file if required.
• The workflow can be configured to attempt a submission to BACS even with items removed. Alternatively, the workflow can be configured to fail completely if even one issue is found.

Workflow Configuration

Service

The Pre-submission Validation node can be used to validate both BACS and Faster Payments submissions. Due to differences in the scheme rules you must tell the node what type of submission it will be validating. The workflow will then validate the submission using the correct set of rules for the payment service.

Reference

This is the submission reference. This is used throughout Paygate such as in reports and submission history. You’ll want to give the reference a meaningful title such as ‘Payment run’ or ‘Monthly DDs’. The reference has a maximum length of 18 alpha numeric characters.

Contra Narrative

Optional add a Contra Narrative for the submission here. The Contra Narrative can ve up to 18 characters in length.

Exception Handling Behaviour

This section describes the configuration options for handling exceptions (errors) during the automated workflow.

In an automated submission, the name of the game is to carry out as much processing as possible in an automated way. This would be fine if payment data was always 100% clean and valid. In the real-world errors creep into payment data and Paygate is able to scan a payment file and determine which transactions are valid and which will cause a payment problem.

All payment instructions must validate

The default setting is ‘All payment instructions must validate before the entire submission can continue’. In this configuration, all of the individual transactions in the entire payment submission must correctly validate or the entire submission is halted and the workflow will stop.

Remove invalid transactions

The default setting may be a little inflexible to you and you may wish to try and submit as many ‘good’ transactions as possible. During pre-submission validation, Paygate grades errors in a number of ways:

Fix

These are transactions that will definitely fail to be process by either BACS/Faster Payments or the banks involved. Since they will definitely fail, Paygate will never attempt to submit them to BACS or Faster Payments.

Warnings

These are transactions that Paygate has determined may cause a problem during the clearing and settlement process. You can remove these transactions from the submission by checking the ‘Warning’ check box. If you do not select this option and warnings are found - Paygate will attempt to submit them but they may fail at a later stage.

Duplicates

Duplicate transactions in a payment file are often a sign of a problem in the payment data. When you select the Duplicates option, Paygate will remove all duplicates from the submission. There are always, at least, two duplicates and both are removed. We remove both duplicates (rather than leave one) because it is an ambiguity that probably requires a manual review.

Note: This process only looks for duplicates in the particular file being processed. Historical payment data is not considered at this stage.

Save removed transactions to a file

If transactions are removed from a submission, Paygate can compile a report of those transactions and the reason why they were removed. By selecting this option Paygate will compile the removed transactions and save them to a location on your Paygate file area. A number of file formats are available:

• Simple CSV
• Simple JSON

Save Path

This is the location in your Paygate secure file area where either the CSV or JSON formatted list of removed transactions will be stored.

Pre-Submission Validation Errors.

The Pre-Submission Validation stage will store any messages that are produced. These messages could be:

• Fixes: Error that will cause BACS to fail the entire submission.
• Warning: Issues with the data in the submission that may indicate invalid data in the submission.
• Info: Various non-error messages

If a workflow fails because of pre-submission validation errors then you will want to view these messages so that the data can be corrected.