Software architecture
The best-of-breed component approach adopted for the platform architecture follows through to the software architecture. This provides its inherent flexibility and the greatest measure of future-proofing.
The key elements are:
- Input/Output (I/O) handler and adapters – affords users a choice of input channels, from our own Enhanced Transmission Service (ETS) to the VocaLink SWIFTNet Transmission Service and the BACSTEL-IP channel used by over 100,000 businesses in the UK.
- Safe store: data from input channels is copied in its original input format before any necessary message format conversion is carried out.
- Payment engine: a tightly integrated set of components including validation, routing and settlement that can be configured to support specific schemes and services.
- Reference data: this intelligent database contains live information about senders and receivers, including which services they can use and what functions they can perform. Tiered access to the system allows privileged users to update the permissions of users under their jurisdiction.
- Process and exception management: this creates alerts or notifications and provides approval workflow for customers when an error is found that needs operator intervention. The functionality is provided via a browser interface and uses worklist-based processing.
- Management information and charging: based on an Enterprise Data Warehouse and using an Extract, Transform and Load (ETL) tool, this component creates customised management information and charging reports.
- Report broker: standard or customised reports, whether regular or ad hoc, are available in XML and XHTML formats.
- Archiving: this stores payment information for a configurable period. It is composed of a soft archive using disk-based technology and a hard archive based on tamper-evident technology. Sophisticated searches and fraud detection facilities are available as an additional service.
The VocaLink Payment Platform is a centrally deployed system comprising a set of configurable stages that form a processing pipeline for payment instructions. Calls through to external interfaces can be made at each stage to mandate, if the processing rules require, that a response is received before processing moves on to the next stage. These interfaces facilitate key processing functions, such as credit checks, that can usually only be performed within a bank’s own back office. By connecting to external systems, banks can rationalise core processing into a central system, thereby reducing costs.