BACSTEL IP Control Issues

IN CONFIDENCE – for the attention and use of Heads of Audit and their authorised staff only

BACSTEL IP – Control Issues

Background

Prior to the introduction of BACSTEL IP, a significant weakness in the BACS process was the transmission of Input Reports via the postal system and the problems that this created in being able to properly check payment details before the relevant bank accounts had been credited.

Under these arrangements BACS required notification of cancellations by the end of processing day (the second day in the cycle) and yet many organisations did not receive their Input Reports until entry day, by which time it was too late to stop payment.

There was no mainstream alternative to obtain the relevant details from BACS more quickly, but most organisations viewed the resulting risks as very unlikely to crystallise.

With BACSTEL IP, access is now available to the BACS website to view details of the payment files being processed and therefore there is a more timely control in place, but of course this needs to be exercised and evidenced correctly.

An explanation of the BACSTEL IP processing cycle is attached at Appendix 1.

Key Risk Considerations

 The period where a payment file resides on a server before submission to BACS is potentially a vulnerable time and this should therefore be minimised. Access controls on this server should of course be strong.  Service Users who are “Indirect Submitters” (i.e. use a bureau) tend to be exposed to additional risk because of necessary additional stages in the process and loss of direct control over the payment file. (In the past we have raised questions relating to the role of bureau and indemnity to cover costs of any mishandling on their part).  As evidenced (see next section), poor file housekeeping can lead to duplicate payments and it should be confirmed that proper protocols are in place.  It is important for a senior member of staff (for both direct and indirect submitters) to be set up as a “Contact” so that they are notified when an Input Report is available for viewing. That member of staff should ensure that final checks are carefully undertaken with reference back to source systems and initial payment authorisation (such a check could for example prevent duplicate payments).

1  An ultimate safeguard is to ensure that reasonable account limits and item limits are set. It is worth noting that payments which exceed an item limit are shown on the Input Report (they are not stopped). Intelligent use of item limits can therefore provide the Service User with a high value sample for checking all details back to source.

Illustration of Ineffective Controls

For one of our clients, a previous year’s BACS file was processed in error and the controls in place at the time were ineffective in identifying and stopping the payment before bank accounts were credited. Action was then required to recover the over-payments and process the correct file. Whilst the likelihood of error is low, the consequence when the risk crystallises is very high, and this area should therefore feature in all Finance risk registers.

Approach to BACS Testing

Auditors need to understand the processes involved, the controls in place and the responsibilities of the organisations involved. This should involve review of existing documentation and procedures, observation of the processes adopted and should result in a clear understanding of what is happening and the key controls that should be in place and those that are currently applied. Computer Auditors should support this work to provide appropriate technical advice.

Key areas for understanding and coverage are shown below, following which it should be possible to record the risks and then identify the controls which have been introduced by the client to address them. It is important to view the payment process as a whole from “end to end” – i.e. from release on the source system through to Input Report checking. This helps to ensure that there are no gaps in control through the whole process and that there is effective segregation of duties at appropriate stages. Suggested key questions to ask are the following:

 How are BACS files created, processed and archived/deleted?  Which applications are used and how are files transferred between them?  Does the NHS body transfer files directly to BACS or is a third party involved?  If a third party is used, how are files transferred to them and then onward to BACS?  What processing controls are exercised by the third party and are these documented and understood by the NHS body, including its own role in checking reports and dealing with error messages?  Are files encrypted and are the transfer processes secure?  How long are files retained on host systems before transfer to BACS/third party and are they secure?

2  What controls are in place to confirm that the correct files are picked up, transferred and processed appropriately?  What transmissions reports are available to confirm that files have been received/ processed and how and when are these checked? Is this done in a timely manner and suitably evidenced?  Is action taken to confirm that the correct files have been processed by BACS (via their web-site) and is this done in a timely manner and evidenced?  Are procedures documented and do they reflect current operations?  Are staff aware of their responsibilities and are there clear and effective arrangements in place for cover for sickness/absence, to include receipt of reports and emails?  Are BACS smartcards and passwords held securely?

Key Controls

Clearly these can only be determined once the system has been understood, documented, appropriate walk through tests conducted and a risk assessment undertaken. To help in forming a view, my own opinion is that the following should be present:

 Immediately prior to transmission, either to an approved third party or to BACS, confirmation should be obtained that the correct file is being processed by agreeing file totals and numbers of transactions back to the payments schedule. This should be evidenced.  Where transmission reports are available, the same totals should again be checked to confirm that the correct file has been received. This should be evidenced.  Where files are sent to a third party for onward transmission to BACS, then any transmission reports or confirmation emails should be checked and evidenced, and any error messages reviewed, actioned and annotated.  Any transmissions to third parties should be encrypted, or appropriate controls introduced to ensure that the correct file has been received and processed.  Confirmation should be received (from either the third party or from BACS) that the Input Report is available on the BACS website and this should be promptly checked for file totals, number of transactions and highlighted items (where applicable) and these checks evidenced. This should be done immediately the file is available, which should be on day 1 of the cycle, i.e. input day  Once BACS files have been transferred, they should be archived and no longer be readily available for transmission (thus avoiding duplicate payments)  All processes should be documented and identify staff responsibilities. The documentation should cover the activities undertaken by third parties.  Individuals responsible for BACS should not have access to process or authorise transactions on the payments system.

3 Where relevant checks are required to be evidenced, this should always include the date it was carried out.

This guidance note only covers the BACS processing part of the system and does not pick up financial control issues regarding the approval of payments, checking and reconciliation of bank statements etc. These issues will need to be covered as part of the broader review of the payments cycle.

Phil Roddison Head of Internal Audit 5 September 2006

4 Appendix 1

The BACSTEL IP Processing Cycle

The processing cycle has three stages that take place on three consecutive processing days; this is the three-day cycle. In addition, “arrival” is the stage that a submission is received by the BACS service and divided into day sections. This is often the same day as the input stage.

ARRIVAL INPUT PROCESSING ENTRY DAY 1 DAY 2 DAY 3 The day a A day section is The payment Valid payment submission is input into BACS full information is instructions received. This is validation. An processed by the (including contras) often the same as input report is relevant financial are applied to input day. Checks available. This institutions. accounts on or are made on the tells you if any after day 3. structure of the payment payment instructions have information and it is been rejected, split into day returned or sections. * amended.

* The payment instructions in a payment file with the same processing date are known as a “day section”. A single processing day file is made up of one day section because all the payment instructions are processed on the same day. You get an input report to confirm processing of day sections; so for a multiprocessing day file, you may get multiple input reports.

We understand that payments can still be stopped on processing day. As would be expected, this increases in difficulty with the number of transactions and financial institutions which have to be contacted and the time of day the sponsoring bank are notified. In practical terms, it seems unlikely that there would be time for the sponsoring bank to make the necessary arrangements much beyond 4:00pm on processing day - but it may still be possible. However, any organisation which wants to rely on the possibility of being able to stop payments on processing day should make their own enquiries about its feasibility. Our strong advice is that input reports should be checked immediately on notification of their availability (which should be on day 1 of the cycle – input day).

In cases where payments need to be stopped, contact should be made with either the BACS Service Desk or the computer banking / BACS liaison section of the organisations sponsoring bank. The BACS Service Desk operates up until 23:00 hours on weekdays (not bank holidays). Sponsoring banks have dedicated help lines but may have more restricted hours. A list of these helpdesk numbers and the BACS Service Desk number can be obtained from the BACS website. http://www.bacs.co.uk/BPSL/bacstelip/