Once you have configured the SmarterPay system, using the Administrator, you can use the software to connect to Bacstel-IP. The SmarterPay client handles everything relating to the Bacs financial services system and is divided into four sections: Payment Files, Active Submissions, Archived Submissions and Reports.
Payment files will be imported into the SmarterPay client, either as payment files or as active submissions (depending on the configuration set up for individual service users).
Even if payment files are imported as active submissions, they will still be accessible from the Payment Files page of the SmarterPay client.
Certain details of payment files can be amended, if necessary, from the Payment Files page.
If they are not already part of a submission, they can be used to create an active submission.
An active submission is created in one of two ways, determined by the configuration setting:
Validation of the payment file account details occurs when you attempt to sign a payment file or an active submission. This is called pre-submission validation. For more details, please refer to the section entitled Pre-submission validation.
Every submission, containing one or more payment files, has to be signed before it is sent to Bacs.
The electronic signature uses valid PKI credentials belonging to a contact that has a valid link to the service user number used in the submission.
Your bank will have decided whether payment files from your service user also have to be signed or not. If they have decided that payment files must be signed, then the signature on the payment file will be validated when Bacs receive the file.
If you are not required by the bank to sign payment files, you may still sign them if you wish to do so, for added security. The signature will be validated by Bacs.
Payment files may be signed by someone other than the contact who signs the submission, providing both signers have a valid link to the service user and the appropriate privileges given to them.
Submissions and payment files should be signed on the same day as they are sent to Bacs, preferably immediately before sending. This will minimise the risk of digital certificates expiring between the signing and the sending. It will also help to avoid the possibility of the processing date of the submission becoming invalid.
Once the submission has been successfully signed by an authorised user it can be sent to Bacs. Before it arrives at Bacs the transmission may fail for some technical reason or it may be aborted by the user. If this happens, the submission will have to be signed again before it can be re-sent.
Once a submission has arrived successfully at Bacs and passed their validation process, Bacs will create reports to notify the service user of each payment file's progress through the Bacs system. These reports can be downloaded and looked at in detail on the Reports page of the SmarterPay client.
If you submit a payment file by mistake, you can contact your bank or building society to request the withdrawal of the payment file, as long as you do so on or before input day. Removing a payment file will result in the creation of a withdrawal report.
For each payment file that has not been rejected or withdrawn, an input report will be created. Once you have downloaded and read the Input report for a specific submission, the submission can be archived. Archiving may be done automatically, using the File Retention section of the Administrator, or manually, depending on your preference.
The process is shown in diagrammatic form below. Green areas show the normal processing stages, while the purple areas show the different points at which the normal processing can be diverted. The Arrival report, in yellow, will only be created if certain errors are detected within the submission or file. For more information, please refer to the section entitled Bacs responses.
More:
As mentioned above, Bacs will create reports at different stages of a file's progress through its system. The first report you may receive in response to a submission is the Rejection Arrival report. Certain validation will be done on the file on the day the submission arrives at Bacs. If the validation is successful, the file will then be held in suspense until the input day arrives. (The arrival day may be the same as the input day, but files can be submitted in advance of input day). However, if errors are detected within the submission or file, a Rejection Arrival report will be produced.
The most common reason for rejection on arrival is Bacs' detection that a duplicate payment file has been submitted (i.e. the same payment file has been submitted more than once for the same processing day).
When input day arrives, full validation will be carried out on the submission, using the full set of reference data held by Bacs. This stage of the process will result in the creation of an Input report. If any errors are detected at this stage, an Input Report indicating the reason for rejection will be produced.
The steps involved in Bacs receiving and processing a submission and the payment instructions being applied to the destination bank/building society accounts is called the processing cycle. For full details please refer to Section 2.6 of the Bacs Service User Guide.
The processing cycle has three stages:
The processing cycle currently takes a minimum of three days. In this cycle, each of the three stages takes place on consecutive “Bacs processing days”.
Input to Bacs full validation and processing of payment instructions can only happen on “Bacs processing days”. Days on which Bacs will not validate or process data include Saturdays, Sundays and English bank and public holidays. Some other bank holidays may also be included in the non-processing days. All other days are Bacs processing days.
When you create a payment file, you have to specify a processing date on which the payment file should be processed by Bacs.
N.B. If the date you specify is not a Bacs processing day, the SmarterPay software will replace that date with the next available Bacs processing date following the one you specified.
The processing date you specify may be up to 31 days after the current date when the payment file is submitted.
There are specific times when you are able to send your submissions to Bacs, called the submissions window. The window runs from 07.00 on Monday morning until 22.30 on Friday evening, with the exception of any non-processing days.
Bacs input for the processing day rolls over at 22.30 each evening. All submissions received by Bacs by 22.30 will be input for the current day and processed on the next valid processing day (unless their processing date is in the future). Any submissions not received by that time will not be input until the next valid input day.
There are several situations in which the processing cycle will take longer than three days.
PKI technology is used by Bacstel-IP to authenticate the data originator and to ensure the integrity of the data that is sent to them. Using PKI technology they can be sure that the data has not been intercepted or changed by a third party.
When a contact connects to Bacstel-IP or transmits a submission, his digital signature is used to carry out security checks. This is done by your signing software. The contact simply has to initialise the signing and enter his PIN number.
Before establishing a secure encrypted communications session between SmarterPay and Bacstel-IP, the PKI technology is used to authenticate the system user who is trying to make the connection. If the system user cannot be authenticated, the communications session will not be initialised.
Once the communications session has been established i.e. authentication was successful, the system user can transmit one or more submissions. Each submission will have been digitally signed, either by this or another system user, and this signature will be used by Bacstel-IP to check that the data within the submission has not been intercepted or changed by a third party.
Digital certificates are held on the smart card issued to your company by Bacs or by your bank or building society. Anybody who wants to connect to Bacs needs a certificate, even if only to retrieve reports. The certificate is used to create a digital signature.
For further information, please refer to section 3.4 of the Bacs Service User Guide.
There are three distinct layers of security in the Submissions application. These are:
Nobody can gain access to the SmarterPay system unless they logon using their username and password.
Passwords must:
Password History:
On password reset, either requested or through expiration, users cannot reuse the last 12 passwords.
Password Expiration:
Password Expiration is controlled under Server Settings.
Once logged on, each user is restricted in the actions the user can perform, depending on the configuration of his user details in the Administrator.
Users with permission to access Bacstel-IP must comply with the security requirements of Bacstel-IP. This means that they must use their smart card certificate to provide a digital signature on submissions they create and to identify themselves when logging onto Bacstel-IP or downloading reports.
All these security aspects together make the SmarterPay client as secure as possible using current technology. All you have to take care of is the human error element. Each system user has the responsibility to ensure that he logs off whenever he leaves his desk unattended, never allows his username and password to be made known to unauthorised personnel, and never allows his smart card to be used by unauthorised personnel.
Whenever you want to use the SmarterPay system, you have to logon using the username and password assigned to you in the Administrator. If you forget your password you must ask your SmarterPay system administrator to reset it for you.
This area of SmarterPay security is as restrictive or as loose as you have made it, depending on the way you have set up the permissions for each system user in the Administrator.
Ideally you will have thought about which users should be given smart cards and which functions they should be allowed to perform, and allocated them to the appropriate security groups.
PKI credentials (i.e. a smart card containing a valid certificate) are required in order to carry out the following actions:
Every submission, containing one or more payment files, has to be signed before it is sent to Bacs.
The electronic signature uses valid PKI credentials belonging to a contact that has a valid link to the service user number used in the submission.
Your bank will have decided whether payment files from your service user also have to be signed or not. If they have decided that payment files must be signed, then the signature on the payment file will be validated when Bacs receive the file.
If you are not required by the bank to sign payment files, you may still sign them if you wish to do so, for added security. The signature will be validated by Bacs.
Payment files may be signed by someone other than the contact who signs the submission, providing both signers have a valid link to the service user and the appropriate privileges given to them.
Submissions and payment files should be signed on the same day as they are sent to Bacs, preferably immediately before sending. This will minimise the risk of digital certificates expiring between the signing and the sending. It will also help to avoid the possibility of the processing date of the submission becoming invalid.
Whenever you attempt to sign a submission or a payment file, some checks will be performed prior to the successful signing.
Checks are made in the following areas:
The account number and sort code must be found on the list, updated frequently from Bacs records, against which SmarterPay makes its checks.
If pre-submission validation is unsuccessful, you will see a dialog listing any errors that were found. You should try to correct these before attempting to sign the file again.
Pre-submission validation may also generate warning messages. These do not prevent you sending the submission to Bacs, but you should read the warning messages carefully to find out what the result will be of not amending the submission.