STEP2 Pan-European Bulk Payment Processing System. Functional Overview

Size: px
Start display at page:

Download "STEP2 Pan-European Bulk Payment Processing System. Functional Overview"

Transcription

1 STEP2 Pan-European Bulk Payment Processing System Functional Overview Final 3v1 of 11 th September

2 Contents 1 Introduction References Modification History The Scope Of The STEP2 Service General Service Description The Phase One Cross Border Credit Transfer Service STEP2 Operation Overview Input Files & Validation STEP2 Routing Routing Tables The Routing Process The Daily Cycle Settlement in EURO1/STEP Settlement Files Reconciliation Files Daily Reconciliation Report (DRR) Monthly Statistics Report (MSR) Enquiries Tracking the status of input and output files Tracking the status of payment instructions Routing table information Phase One STEP2 Implementation STEP2 Participant System Receiving Payment Instructions Via The Single Message Interface Receiving Payment Instructions Via The File Interface Receiving Settlement Results From The STEP2 Central System Settled Payment Files (SPF) Cancelled Payment Files (CPF) Receiving Reconciliation And Statistical Information From STEP Local Management Interface Access To The Participant System Repository Physical Implementation (EBA-MPS)

3 3

4 1 Introduction This document presents a general description of the STEP2 pan-european payment processing service operated by SIA on behalf of the EBA. The information presented in this document is as follows: An introduction to the scope of the STEP2 service in general and the specific functionality of phase one; An explanation of the operation of phase one of STEP2; and A description of the STEP2 participant system developed and operated by SIA for the EBA. Readers who require further information should refer to those documents listed in the References section, below. 1.1 References [1] STEP2 Interface Specification FINAL 3.0, 14 September 2004 [2] STEP2 Central System Functional Specification FINAL 3.0, 14 September 2004 [3] STEP2 Participant System Functional Specification FINAL [2].0, 25 September 2003 [4] SWIFT Draft Bulk Payments Messaging Report Version 1.4, July 2002 SWIFT 1.2 Modification History Version Date Status /06/2002 First Draft /09/2002 Re-work following agreement of functional specifications and interface specification /10/2002 Internal review with EBA / SIA /10/ /11/2004 FINAL version 1v4 October 2002 DRAFT 3v0 October 2004: New Logo; New Settlement Cutoff time; Compressed files functionality /06/2006 Draft 3v1 September 2006: Resending cancellations functionality 4

5 2 The Scope Of The STEP2 Service 2.1 General Service Description Payments for processing in files STEP2 Pan-European Bulk Payment Processing Service Processed payments in files Sending STEP2 Participant Bank Settlement obligations resulting from STEP2 processing Receiving STEP2 Participant Bank External Settlement Mechanism Figure 2-1 STEP2 Pan-European Bulk Payment Processing Service STEP2 is a high volume, low value, non-urgent commercial and retail payments processing service capable of routing payments between STEP2 participants and any bank within the EU. Admission to STEP2 is reserved for banks that have a registered office or branch within the EU. STEP2 accepts bulk payments in files (both in compressed and uncompressed format) from sending participants formatted in accordance with published STEP2 file standards over secure network connections. Accepted files contain payment instructions that are formatted in accordance with international standards. Payments accepted for processing are aggregated and the resulting gross obligations are processed via the services of an external settlement mechanism. Successfully processed payment instructions are forwarded to receiving STEP2 participants in files. Following settlement, STEP2 provides all participants with comprehensive information to assist reconciliation. STEP2 is being introduced in phases. Phase one of STEP2 is summarised in section 2.2, below, and discussed in detail in the remaining sections of this document. STEP2: Is simple to use, Provides the highest levels of security, Minimises the cost of connection, Minimises the cost of payment routing and reconciliation, and Facilitates the highest rates of STP. 5

6 2.2 The Phase One Cross Border Credit Transfer Service Payments for processing from ordering banks Sending Direct Participant Payments for processing in files STEP2 Central System Settlement obligations resulting from STEP2 processing Processed payments in files Receiving Direct Participant Processed payments for beneficiary banks EURO1 / STEP1 Figure 2-2 STEP2 Phase One Cross Border Credit Transfer Processing Service Phase one of STEP2 processes cross-border credit transfers, which are settled in EURO1/STEP1. Banks participating in the phase one STEP2 service may choose to send and receive files of payment instructions directly to and from the STEP2 central system or to send and receive payment instructions via the services of a directly connected STEP2 participant bank. Direct connection is open to banks that are members of EURO1 or STEP1. Banks that wish to receive processed payment instructions via a single direct participant must be known to STEP2 as indirect participants. Direct participants are known to STEP2 via their eight-character BIC. A bank may have more than one direct participant in STEP2; any bank or branch that has a unique BIC (8) can participate in STEP2 directly. STEP2 also uses a different BIC to identify direct participants for settlement purposes within EURO1/STEP1. More than one direct participant can settle within EURO1/STEP1 via the same settlement BIC, allowing multiple directly connected branches of a bank to share liquidity in EURO1/STEP1. Following settlement, STEP2 forwards files of successfully processed payment instructions to receiving direct participants. At the end of a processing day, reconciliation information is forwarded to all direct participants in files. All files are designed to be machine-readable. Direct participants may also choose to receive monthly statistical information on the usage of the STEP2 system to assist charging. An online enquiry interface is provided so that direct participants may enquire upon the status of their files, payment instructions, and settlement instructions within the STEP2 central system. The flow of payment instructions and funds between direct participants and the banks to which they provide a service is outside the scope of STEP2. The STEP2 participant system does, however, contain functionality to assist with the reception of payment instructions from ordering banks and the distribution of processed payment instructions to beneficiary banks (see below). Phase one of STEP2 processes STEP2 formatted files containing payment instructions formatted in accordance with SWIFT MT103+ and SWIFT Bulk Payments Messaging Group, XML STP Bulk Credit Transfer standards (further information on the XML standard is provided in reference [4]). To connect, direct participants can enhance their payment systems to connect directly to the STEP2 central system and generate and receive files formatted in the STEP2 standards. Alternatively they can connect their payment systems via the STEP2 participant system. The STEP2 participant system presents a variety of interfaces to payment systems to reduce the effort required to connect to STEP2. The STEP2 participant system is discussed in more detail in section 4. The following sections provide a more detailed overview of the phase one STEP2 service. 6

7 3 STEP2 Operation 3.1 Overview The STEP2 phase one cross border credit transfer processing service settles via EURO1/STEP1. The following information reflects this approach. Services provided in future phases of STEP2 that also settle in EURO1/STEP1 (such as cross border direct debits) may also share this structure. Services that settle outside of EURO1/STEP1 (such as domestic payment services) may require a different set of structures. Additional information regarding future services will be provided prior to their onset. Phase one of STEP2 is shown in Figure 3-1. Ordering Indirect Participant Or Ordering Non-Participant Sending / Ordering Direct Participant Scope of the STEP2 Service STEP2 Central System Receiving / Benficiary Direct Participant Beneficiary Indirect Participant EURO1/STEP1 Beneficiary Non-participant via Receiving Direct Participant as nominated Preferred Agent of Sending Direct Participant Figure 3-1 The Phase One STEP2 Service Communication with STEP2 takes place via STEP2 formatted files. Banks that are also members of EURO1 or STEP1 may send and receive files of payment instructions directly to and from the STEP2 central system. Such banks are referred to as direct participants. Other banks must send and receive payment instructions via the services of a direct participant. Banks that are not direct participants who wish to receive STEP2 payment instructions via the services of one and only one direct participant must be known to the system as indirect participants. Direct participants are also settlement participants in STEP2 (in which case they are EURO1 members) or non-settlement participants in STEP2 (in which case they are STEP1 members). The flow of information and funds between settlement and non-settlement participants is outside the scope of STEP2 but is supported by the normal EURO1/STEP1 processes, which have been enhanced to support the processing of STEP2 payments. The distinction between settlement and non-settlement participants is therefore largely invisible to the operation of the STEP2 central system. A direct participant may transmit files to the STEP2 central system containing payment instructions where the direct participant is: The ordering bank, or The sending bank on behalf of another EU bank as ordering bank. Files of payment instructions for processing are referred to as Input Payment Files (IPF). IPFs received by the STEP2 central system are first validated. The results of the validation process are returned to the sending direct participant in a File Validation Report (FVR). One and only one FVR is returned to a sending direct participant in response to an IPF. IPFs and the validation process are discussed in more detail in section

8 Validated payment instructions are routed using the beneficiary bank to choose the direct participant which will be the receiver of the payment instruction following settlement. Payment instructions for an indirect participant as beneficiary bank are routed to the direct participant through whom they receive processed payment instructions. Payment instructions for beneficiary banks that are unknown to the system are routed to the preferred agent for the country in which the beneficiary bank is resident. The preferred agent is nominated by the direct participant that sent the file containing the payment instruction. The routing process is discussed in more detail in section 3.3. Following routing, payment instructions are processed in accordance with a published settlement cycle. Settlement obligations are calculated by aggregating and sorting payment instructions by receiving direct participant to produce bilateral gross settlement instructions, and these settlement instructions are then forwarded to EURO1/STEP1 for processing. The daily settlement cycle is discussed in more detail in section 3.4. No sender cancellation option for either files, or payment instructions within files, is available in phase one of the STEP2 system. Payment instructions are therefore irrevocable in STEP2 once transmitted to the central system. A sender cancellation option may be added in a future phase of STEP2. This functionality is likely to coincide with the addition of payment warehousing functionality. In phase one, no support for returns is provided in STEP2; all return payments must be handled outside of STEP2. Following successful settlement, processed payment instructions are transmitted to receiving direct participants in Settled Payment Files (SPF). Direct participants receive processed payment instructions in SPFs where they are: The beneficiary bank of the payment, The receiver of the payment on behalf of one of their indirect participants as beneficiary bank, or The preferred agent nominated by the sender of the payment instruction for a beneficiary bank not known to STEP2. In the (rare) event where EURO1/STEP1 processing of all STEP2 settlement instructions does not complete within the settlement cycle timeframe, the remaining settlement instructions are cancelled within EURO1/STEP1, and the STEP2 payment instructions related to the cancelled settlement instructions are returned to the relevant sending direct participant in a Cancelled Payment File (CPF). A maximum of one CPF is transmitted to a direct participant for every IPF received by STEP2 from that direct participant. SPFs and CPFs are discussed in more detail in section 3.5. Following the completion of a daily settlement cycle, reconciliation information is transmitted to all direct participants in Daily Reconciliation Reports (DRRs). Following the completion of the daily processing cycle on the last operating day of a calendar month, direct participants may optionally receive a Monthly Statistics Report (MSR), which supplies statistical information on their usage of STEP2 to assist with their charging processes. Reconciliation information is discussed in more detail in section 3.7. At any time, direct participants may enquire upon the status of their files, settlement instructions, and payment instructions via an online enquiry terminal. STEP2 enquiries are discussed in more detail in section 3.8. The physical implementation of the phase one STEP2 service, including the methods for direct participant connection and facilities for the EBA to control the service, is discussed in detail in section 3.9. Further information on STEP2 file formats and interfacing to the STEP2 system is provided in reference [1]. Further information on the operation of the STEP2 central system is provided in reference [2]. 8

9 3.2 Input Files & Validation Payments for processing are transmitted to STEP2 in Input Payment Files (IPF). An IPF can be sent in uncompressed and compressed format. An IPF contains header information and one or more payment instructions for processing. IPFs can be transmitted to the STEP2 central system in fixed field or XML formats. The header information of both file types contains, amongst other information: A Sender s File Reference (SFR) used to uniquely identify the file within STEP2; The creation date of the file; The STEP2 service to which the payment instructions are submitted (in phase one there is one service referred to as XCT X-border credit transfers); and The total number and total value of the payment instructions contained within the file. Fixed field files contain payment instructions formatted in accordance with the STEP2-specific sub-set of the SWIFT MT103+ format. XML files contain payment instructions formatted in accordance with the SWIFT Bulk Payments Group Credit Transfer Message format. Both formats contain identical information and the STEP2 central system freely translates between the two formats, when necessary (for example allowing payment instructions for processing received in MT103+ format to be distributed, following processing, in XML format). In order to ensure the highest levels of STP, the STEP2 central system validates each IPF it receives in accordance with a set of strict validation rules. In summary, these validation rules are as follows: 1. The security credentials of the file must be correct. Files with incorrect security credentials are immediately rejected and not subject to any further processing. 2. The file must be identifiable as an IPF. Files that do not have the expected structure are immediately rejected. 3. The sending direct participant must subscribe to the indicated service ( XCT in phase one). 4. The Sender s File Reference (SFR) must be unique by direct participant, STEP2 service, and creation date. An IPF received with an SFR that is the same as another file received for the same service on the same day from the same direct participant is discarded as a duplicate. However, SFRs from rejected IPFs may be re-used until the IPF is accepted. It is therefore not necessary to give an IPF a new reference when it is re-transmitted following correction. 5. The total number and value of payment instructions in the file must match that indicated in the header. 6. The payment instructions within the file must pass the payment instruction validation rules for the service to which they are the directed. For the phase one cross border credit transfer service there is also a limit on the maximum value of an individual payment instruction (there is no limit on the maximum total value of payment instructions in a file). Transaction Reference Numbers (TRNs) on each payment instruction must be unique by ordering bank, sending direct participant, STEP2 service, and value date (each instruction includes the value date). In phase one, no payment warehousing is supported. Payment instructions with a value date other than that currently being processed are rejected. Files that fail validation checks 1 through 5 result in the complete rejection of the file. Files containing payment instructions that fail the validation checks in 6 above (payment instructions) result only in the rejection of the offending payment instructions. Following validation, a File Validation Report (FVR) is returned to the sending direct participant indicating the success or failure of the validation process and the reason for any failure. FVRs for IPFs that passed validation checks 1 through 5 but contain invalid payment instructions include a copy of each of the invalid payment instructions with an appropriate rejection reason code for every such instruction. A complete specification of the format of IPFs, FVRs, and all validation checks performed on IPFs is given in reference [1]. 9

10 3.3 STEP2 Routing STEP2 can address any bank within the EU as the beneficiary bank of a payment it receives. In order to achieve this, payment instructions received by STEP2 are routed using the beneficiary bank (field 57A / Final Agent) of the payment instruction. To identify the receiving direct participant, the routing process uses routing tables configured within the STEP2 central system. This process is explained below Routing Tables Payment instructions are passed through the STEP2 routing process to identify the direct participant that will receive the payment instructions following settlement. This routing process uses routing tables that mirror the physical and commercial connectivity between direct participants and their indirect participants. The routing tables also identify direct participants as preferred agents through which payments for unknown beneficiaries should be routed. The routing table contains: A list of BICs for each direct participant, STEP2 BIC (8) Direct Participant EURO1/STEP1 Settlement BIC(11) BIC-a DP-1 BIC-1 BIC- BIC-x DP-N BIC-N Each direct participant may also specify a different BIC that will be used for settlement instructions within EURO1/STEP1. More than one direct participant may share the same settlement BIC (allowing a bank to have several branches defined as direct participants all settling via a common BIC in EURO1/STEP1). A list of BICs for each indirect participant mapped to the direct participant through whom they receive payments and payment instructions. BIC (11) Indirect participant Direct participant BIC-a IP-1 DP-X BIC- BIC-z IP-M DP-Y For each direct participant, a mapping of each EU country to the preferred agent through whom payments destined for beneficiaries within that country should be settled. Preferred agents must also be direct participants. Direct participant Preferred Agent Country 1 Country 2 Country n DP-1 DP-W DP-X DP-Y DP-Z N.... Direct participants need not be physically located within a country in order to provide a preferred agent service for that country. However, all direct participants must nominate within STEP2 a preferred agent for each EU country. 10

11 3.3.2 The Routing Process Payment instructions are routed as follows: 1. The table of direct participants is checked. If the beneficiary bank is a direct participant, then the payment is routed to that participant as receiver. 2. If the beneficiary bank is not a direct participant, then the table of indirect participants is checked. If the beneficiary bank is an indirect participant then the payment is routed to the direct participant related to the indirect bank. 3. If the beneficiary bank is not an indirect participant then it is unknown to the system. The country within which the beneficiary bank resides is identified (from the BIC) and the payment is routed to the preferred agent nominated by the sending direct participant for unknown beneficiaries in that country. This is shown in Figure 3-2, below. Route Payment 57A is a DP? Y Receiver = 57A Stop N 57A is an IP? Y Receiver = DP of 57A Stop N Receiver = preferred agent of sending DP Stop Figure 3-2 Routing process 11

12 3.4 The Daily Cycle The flow of information between direct participants and the central system is shown in Figure 3-3. The timing of the processing phases generating this information is shown in Figure 3-4. Both are explained below. Sending Direct Participant STEP2 Central System Receiving Direct Participant 1 2, 5, 7 6, Figure 3-3 Central System Information Flow # Stage Processing 1 Transmission of IPFs To STEP2 2 Transmission of FVR To Sending Direct Participant 3 Transmission of Settlement Instructions to STEP1/EURO1 4 Reception of Settlement Responses from STEP1/EURO1 5 Transmission of CPFs To Direct Participants (in rare cases) 6 Transmission of SPFs To Direct Participants 7 Transmission of Reconciliation Reports To Direct Participants STEP1/EURO1 Direct participants transmit their Input Payment Files (IPF) to the STEP2 central system. Phase one of STEP2 is a single settlement cycle, single value date system. IPFs received after the sending cut-off will therefore be immediately rejected. In a future phase, direct participants may be able to send IPFs at any time. The STEP2 central system validates each file and responds with one and only one File Validation Report (FVR). At the sending cut-off time, the STEP2 central system processes all valid payment instructions received and calculates settlement obligations. At the settlement time, the settlement instructions are transmitted to EURO1/STEP1 for processing. At the settlement cut-off time, settlement responses are received from EURO1/STEP1. These can be either indications of success (for settlement instructions that were successfully processed before the settlement cutoff time) or cancellations (for settlement instructions that could not be processed before the settlement cut-off time); settlement instructions are only cancelled under rare circumstances. See 3.5 Settlement in EURO1/STEP1 below for more details. Cancelled Payment Files (CPF) are prepared from the STEP2 payment instructions related to cancelled settlement instructions and these are transmitted to the sending direct participants. Settled Payment Files (SPF) are prepared from the STEP2 payment instructions related to successfully processed settlement instructions and these are transmitted to the receiving direct participants. Daily Reconciliation Reports (DRR) are prepared and transmitted to all direct participants. DRRs are transmitted only when all processing operations have been successfully complete. On the last operating day of a calendar month, Monthly Statistics Reports are prepared for direct participants who wish to receive them. These are then transmitted to direct participants. Table 3-1 Phases Of Information Exchange With The STEP2 Central System 12

13 Opening Sending Cut-Off Settlement Setlement Cut-Off 1 2 Receiving File File Validation Transaction Validation Payment Sorting FVR Transmission Calculation of Bilateral Gross Balances These processes performed for each file received from a direct participant Preparation of Settlement Instructions 3 Transmission of Settlement Instructions 4 Reception of Settlement Responses Preparation of Cancelled Payment Files (CPF) Preparation of Settled Payment Files (SPF) Preparation of Daily Reconciliation Reports (DRR) / Monthly Statistics Reports (MSR) 5, 6, 7 Transmission of Output Files & Reports Day D Day D Figure 3-4 Timing Of Phase One Settlement Cycle A STEP2 service can in principle consist of one or more settlement cycles per value date. Each settlement cycle consists of a sending cut-off time, a settlement time, and a settlement cut-off time. Phase one of STEP2 has only one settlement cycle per day. Payment instructions must be submitted to the STEP2 central system before 10.00pm on day D-1 for value on day D. Phase one of STEP2 is operational on all TARGET days. On non-target days, STEP2 processing ceases at midnight at the end of the previous TARGET day and recommences at midnight at the beginning of the next TARGET day. 13

14 3.5 Settlement in EURO1/STEP1 Phase one of the STEP2 system settles payment instructions using bilateral gross settlement between direct participants. For each direct participant a separate settlement instruction is generated for the sum of all valid STEP2 payments instructions received from that direct participant and routed to each other direct participant. Thus, if there are N direct participants, up to N-1 settlement instructions will be generated for each direct participant. STEP2 sends the settlement instructions in batches to EURO1/STEP1, using the SWIFT FIN network. These messages include the cut-off time by which EURO1/STEP1 is expected to have processed all the instructions. The settlement instructions settle in EURO1/STEP1 in the normal way, but if any have not settled by the cut-off time they are cancelled by EURO1/STEP1. At the cut-off time STEP2 receives a response for each settlement instruction. The STEP2 settlement cycle is timed to maximise the EURO1/STEP1 liquidity available to participants when STEP2 settlement is taking place; the possibility that all settlement instructions will not successfully complete processing is thus very low. Moreover, a specific functionality is available within the system to allow the retransmission to EURO1/STEP1 of the settlement instructions that have been cancelled at the first attempt. If the processing of the impacted settlement instructions remains unsuccessful at the extended settlement cut-off time, the said settlement instructions are definitively cancelled and CPFs are generated for the associated payment instructions. Should this extension of the settlement cut-off time be necessary, it would delay the start of the transmission of output files and reports phase for all direct participants by up to 1 hour. EURO1/STEP1 members can optionally request that when a settlement instruction for STEP2 is processed successfully in EURO1/STEP1, an MT900 Advice of Debit message (for debits to their position) or MT910 Advice of Credit message (for credits to their position) is sent to their main BIC from EURO1/STEP1. STEP2 settlement instructions are also reported in the EURO1/STEP1 MT970 and MT972 netting statements, and are distinguished from other payments in EURO1/STEP1 by having a specific message type (TRF) and a fixed prefix in their Transaction Reference Numbers. Each STEP2 settlement instruction is uniquely identified in EURO1/STEP1 by a Transaction Reference Number which conforms to a well-defined standard. This standard form can be used to assist banks in reconciling the total value of all settlements in EURO1/STEP1 against the total value of all files sent to and received from STEP2 Note that no risk management is provided in STEP2 itself. All risk management is performed within EURO1/STEP1. 14

15 3.6 Settlement Files Following settlement, STEP2 produces: Settled Payment Files (SPF), and Cancelled Payment Files (CPF). SPFs are produced as part of normal system operation. Direct participants can choose to receive the SPF in compressed or uncompressed format. Direct participants can choose to receive one SPF containing all settled payment instructions for which they are receiver or three SPFs containing settlement payment instructions: For the direct participant as beneficiary bank, For the direct participant s indirect participants as beneficiary banks, and For beneficiary banks not known to the STEP2 system where the receiving direct participant is the nominated preferred agent of the direct participant sending the payment instruction. For each payment instruction, an SPF identifies: The sending direct participant (who is also the debit party of the related settlement instruction), and The beneficiary bank. CPFs are only generated in rare cases when EURO1/STEP1 is unable to complete the processing of all settlement instructions before the settlement cut-off time. Direct participants can choose to receive the CPF in compressed or uncompressed format. Complete information on CPFs and SPFs is available in reference [1]. 3.7 Reconciliation Files Following the successful completion of settlement and the preparation of Settled Payment Files (SPF), STEP2 prepares reconciliation information in the form of Daily Reconciliation Reports (DRR). A DRR is always prepared for every direct participant irrespective of whether they have sent or received payments on that day. Direct participants can choose to receive the DRR in compressed or uncompressed format. The content of DRRs is explained in section 3.7.1, below. Participants can optionally receive Monthly Statistics Reports (MSR) following the preparation of DRRs on the last operating day of a calendar month. Direct participants can choose to receive the MSR in compressed or uncompressed format. MSRs contain statistical usage information to assist participants with their charging. The content of MSRs is explained in section 3.7.2, below. For a complete specification of DRRs and MSRs, see reference [1]. 15

16 3.7.1 Daily Reconciliation Report (DRR) DRRs contain the following information: Totals with respect to the direct participant receiving the reconciliation report: Number of files: Sent to the STEP2 central system, Rejected by the STEP2 central system, Files received from the STEP2 central system; and Number and value of payments from accepted files: Sent to the STEP2 central system, Rejected by the STEP2 central system, Held over to next business cycle *, Settled by the STEP2 central system, Cancelled by the STEP2 central system, and Received from the STEP2 central system. For each file sent to the STEP2 central system by the direct participant receiving the reconciliation report: The file identifier; The number and value of payments: Sent to the STEP2 central system, Rejected by the STEP2 central system, Held over to next business cycle *, Settled by the STEP2 central system, and Cancelled by the STEP2 central system. For each payment file received from the STEP2 central system: The file identifier, Number and value of payments received as beneficiary, Number and value of payments received for indirect participants, and Number and value of payments received as preferred agent. Total number and value of all settlement instructions sent to EURO1/STEP1 for payments sent to STEP2. Total number and value of all settlement instructions sent to EURO1/STEP1 for payments received from STEP2. For each settlement instruction sent to EURO1/STEP1 for payments sent to STEP2: The counterparty direct participant BIC, Reference (tag 20), Amount, and Result of settlement. * To support future functionality - not used for phase one of STEP2. 16

17 For each settlement instruction sent to EURO1/STEP1 for payments received from STEP2 The counterparty direct participant BIC, Reference (tag 20), Amount, and Result of settlement Monthly Statistics Report (MSR) MSRs contain the following information, all of which relates to the calendar month ending when the MSR is prepared: Total number and value of payments from accepted IPFs sent, rejected, cancelled, and settled; Total number and value of payments received in SPFs; For each direct participant to whom payment instructions were routed as beneficiary bank or as receiver for an indirect participant as beneficiary bank: The BIC of the receiving direct participant, and The total number and value of payment instructions accepted, cancelled, and settled; For each direct participant from whom payment instructions were received as beneficiary bank or as receiver for an indirect participant as beneficiary bank: The BIC of the sending direct participant, and The total number and value of payment instructions received; For each direct participant to whom payment instructions were routed as preferred agent: The BIC of the receiving direct participant, and The total number and value of payment instructions accepted, cancelled, and settled; For each direct participant from whom payments were received as preferred agent: The BIC of the sending direct participant, and The total number and value of payment instructions received; 17

18 3.8 Enquiries Enquiries on data held online on the STEP2 central system can be made via the Webstation enquiry interface (see section 3.9, below). Data is maintained online for three months before it is archived. Special arrangements can be made for enquiries on data that has been archived. The information available via this interface can assist direct participants with their day-to-day operations by supplementing the summary information and statistics made available via the Daily Reconciliation Report and Monthly Statistics Report. Detailed information on specific payment instructions for which a direct participant is a party is available only via the Webstation enquiry interface. The Webstation enquiry interface provides information on the following: The status of input and output files, The tracking of payment instructions, and The direct participants routing table information. These are explained in more detail in the following sections Tracking the status of input and output files The following fields from the STEP2 file header can be used for enquiries to track the status of files that are held online: Service identifier ( XCT only in phase one), File type (e.g. IPF, FVR, CPF, SPF, DRR, & MSR), Sender s File Reference, File name, and Creation date and time. 18

19 3.8.2 Tracking the status of payment instructions The following fields from the payment instruction can be used for enquiries to track the status of files that are held online: Service Identifier, File Type, Sender s Files Reference, Date and Time, Transaction Reference, Amount Range, Value Date, Ordering Customer, Ordering Institution, Sending Bank, Receiving Bank, Account With Institution, Beneficiary Customer, Status (Awaiting settlement, settled, cancelled), Credit Party, Debit Party, and Settlement Reference Routing table information Direct participants can also view the routing table information related to them within the central system, i.e. their direct participant information, information on their indirect participants, and information on preferred agents. 19

20 3.9 Phase One STEP2 Implementation The phase one STEP2 physical implementation is shown in Figure 3-5, below. Disaster Recovery Systems STEP2 Direct Participant Help Desk Operational Control Local Management Interface Payment System(s) Secure Networks STEP2 Central Processing System Participant System (optional) Back Office Webstation Interface Secure Networks Payment System(s) Ordering Bank / STEP2 Indirect Participant EURO1 / STEP1 STEP2 Business Control EURO1/ STEP1 Business Control ABE EBA Figure 3-5 Phase One STEP2 Implementation The STEP2 central system is hosted at SIA s operational centre. Two systems are provided, a primary system and a secondary system, 15km apart. Both systems are constantly synchronised over a fibreoptic connection and under business continuity arrangements, changeover from primary to secondary can take place with no risk of undetected data loss or duplication. As transaction volumes rise a third site will be added at least 100km from both systems and located within a separate European country. Direct participants exchange files with the STEP2 central system and perform enquiries over secure network connections. Two networks are supported as described in Table 3-2. The network connections employed support two modes of file transfer: Push mode, where direct participants receive files unsolicited, and Pull mode, where direct participants request files from the STEP2 central system. The STEP2 central system and STEP2 participant system always operates in push mode, e.g. direct participants can send files to the STEP2 central system without waiting for the system to request them. 20

21 Network SWIFTNet InterAct & FileAct SWIFTNet InterAct and Browse SIANet File transfer service SIANet IP service Service Secure file transfer Secure browsing Secure file transfer Secure browsing Table 3-2 STEP2 Supported Networks Participants may request that the STEP2 central system manually re-transmits their files. This may be employed by direct participants to retrieve files that may have been lost from their payment systems. Direct participants may choose to enhance their payment systems to support STEP2 file standards or to employ the STEP2 participant system to perform translation from existing standards. The STEP2 participant system is described in section 4. Participants may enquire on the status of their files, settlements, and payment instructions and view their configuration information (such as their routing table) via the Webstation terminal. The STEP2 system provides a test and training mode of operation for verifying the functionality of systems and to provide participants with a safe environment for staff familiarisation exercises prior to live connection. This system is accessible via test and training network addresses. The business operation of the system is controlled by EBA in a manner similar to that employed for EURO1/STEP1. A secure business control terminal is provided at the EBA operational centres over a SIANet connection, allowing EBA operations staff to monitor and control the business processing of the system. The technical operation of the system is controlled by SIA using terminals directly connected to the STEP2 central system. An English-speaking helpdesk is also provided by SIA to assist direct participants with technical enquiries. 21

22 4 STEP2 Participant System The STEP2 participant system developed by SIA for the EBA is shown in Figure 4-1, below. Payment System MQ Series Single Payment Interface File Interface Floppy disk / CD ROM Payment System Offline Media EBA Participant System Files of payment instructions via a secure network STEP2 Central System FTP Local Command Interface Repository Access Database Application MS SQL Server 2000 Views Browser Printing Facilities Direct Participant Figure 4-1 STEP2 Participant System The STEP2 participant system insulates direct participants payment systems from the details of the STEP2 file specifications, allowing a bank to participate in STEP2 directly with the minimum of modification to existing systems. The participant system also detects errors in payment instructions and files allowing the errors to be corrected prior to their transmission across the network. The participant system provides two interfaces, a file interface and a single message interface. Both interfaces may be used simultaneously. The single message interface accepts single payment instructions in SWIFT MT103+ format. Full FIN messages, including blocks 1 through 5 are supported and the participant system intelligently maps these blocks to all direct acceptance of instructions from ordering banks. Validated payment instructions are aggregated into STEP2 format files and transmitted to the STEP2 central system. More details on the reception and validation of payment instructions on the single message interface are provided in section 4.1. The file interface accepts STEP2 formatted Input Payment Files (IPF), validates these prior to transmission to the STEP2 central system and processes additional validation results from the STEP2 central system. Further information on the reception of payment instruction via the file interface is provided in section 4.2. For contingency purposes, the STEP2 participant system can also accept files from offline media, such as floppy disks or CD-ROMs. Settlement results and reconciliation information is received from the STEP2 central system. The participant system can be configured to output the results of settlement via the single message or file interface. Reconciliation information can be either stored on the participant system for local browsing or stored on the participant system and transmitted to the bank s payments systems over the file interface. Further details of the processing of settlement results can be found in section 4.3. Further information on the processing of reconciliation information can be found in section

23 All payment instructions and files received from a bank s payment systems are stored locally in the payment system repository. Access is given to this repository via local browsing facilities and via database views. Further information on local browsing facilities is given in section 4.5 and further information on access to the payment system repository is given in section 4.6. Information on the physical implementation of the STEP2 participant system is given in section Receiving Payment Instructions Via The Single Message Interface The participant system can receive payment instructions for processing from the bank s payment system through a single MQ Series input queue. All payment instructions received are validated against the SWIFT MT103+ format. Successfully validated payment instructions are stored in the participant system as valid. For payment instructions that fail validation, one of three actions is performed: 1. Messages that cannot be recognised as payment instructions are returned unchanged to the bank s payment system using a single garbage queue and are not stored in the participant system. 2. Payment instructions that are duplicates of valid payment instructions stored in the participant system are returned unchanged to the bank s payment system using a single duplicate queue and are not stored. Payment instructions must be unique by STEP2 service identifier ( XCT in phase one), Transaction Reference Number (TRN), ordering bank, and value date. 3. Payment instructions that fail validation checks have a SWIFT rejection code appended to them and are then returned to the bank s payment system as MT103s using a single invalid messages queue. They are also stored in the participant system as invalid payment instructions. Payment instruction Transaction Reference Numbers (TRN) may be re-used until a payment instruction with that TRN is accepted as valid. Full details of duplicate and validation checks performed are specified in reference [1]. Full FIN messages are accepted on the single message interface, including blocks 1 through 5. To facilitate the acceptance of payment instructions from ordering banks, the participant system maps information in these blocks to the block 4 that is placed in the STEP2 Input Payment Files. The mappings performed are as follows: Payment Instruction Field 52A 57A Action If 52A of the source payment instruction is not present and the sender of the source payment instruction (Basic Header, LT Identifier) is not the same as (or is a branch of) the direct participant preparing the IPF then 52A is populated with the sender of the source payment instruction (without the 9 th character). If 57A is present in the source payment instruction then this is used, otherwise the receiver specified in the source payment instruction (Application Header, Receiver s Address) of the source payment instruction is used (without the 9 th character). Table 4-1 Single Payment Interface To IPF Body Mapping Exceptions 23

24 To allow easy migration from existing cross border credit transfer systems, the participant system also strips fields from payment instructions that are valid in the SWIFT standard MT103+ format but not valid in the STEP2 MT103+ format. An entry is written in the participant system audit log to inform direct participants of any fields that are being stripped from payment instructions. The only exception to this rule is field 56A; payment instructions that contain field 56A are always rejected. The participant system aggregates valid payment instructions received via the single payment interface into Input Payment Files (IPF) ready for transmission to the STEP2 central system. This aggregation occurs: When manually requested to do so from the Local Management Interface by a suitably authorised user, At configurable specific times, and / or When a configurable number of valid messages have been received. Phase one of STEP2 supports only one cross-border, credit transfer service and therefore only crossborder, credit transfer files will be generated (where the service identifier is XCT ). Future phases will support other services and the participant system will then use the service identifier (field 103 of block 3 / User Header) of received payment instructions to create files specific to the supported services. After creating the IPF, the participant system automatically transmits it to the STEP2 central system. In the event of a transmission error, the participant system will retry for a configurable number of times. If the file still cannot be successfully transmitted because of an irrecoverable error, the participant system will raise an error event in the system, and operator intervention is required to recover the problem and restart the sending operation The STEP2 central system validates all files it receives against a set of validation rules defined in reference [1] that are a super-set of the validation rules enforced by the participant system. The results of this validation process are automatically transmitted by the STEP2 central system to the participant system in a File Validation Report (FVR). The processing performed by the participant system depends upon the type of FVR received, e.g. successful validation, partial rejection, or complete rejection: Upon receipt of a FVR indicating successful validation of an IPF generated from messages received via the single payment interface, the participant system stores the FVR and updates the internal status of the validated payment instructions. No indication of success is returned to the bank s payment system. Upon receipt of a FVR indicating partial rejection of the IPF, the invalid messages in the FVR are returned to the bank s payment system as MT103s by the participant system using an invalid messages queue. (For partially rejected IPFs, the STEP2 central system appends the appropriate error code to all rejected messages in the corresponding FVR.) Upon receipt of a FVR indicating complete rejection of the IPF, all messages transmitted in the rejected IPF are returned to the bank s payment system as MT103s by the participant system using the invalid messages queue. Before returning the messages the participant system appends an error code to each message that states the file rejection reason. 24

25 4.2 Receiving Payment Instructions Via The File Interface The file interface can be used to communicate with external payment systems that are capable of generating and processing standard STEP2 file formats. The file interface is structured via a number of FTP locations that are used to input and output files of particular categories. The participant system receives incoming IPFs sent by the bank s payment system through a single file input location. All files received by the participant system from the bank s payment system(s) are first validated. In the case of successful validation, the file is stored in the participant system file catalogue as a valid file and all payment instructions within the file are stored in the participant system as valid payment instructions. In the case of negative validation, one of three actions is performed: Files that cannot be recognised as an IPF from the correct sender are returned to the bank s payment system using a garbage location and are not stored in the participant system file catalogue. Files that are duplicates of valid files already stored in the participant system file catalogue are returned to the bank s payment system using a duplicate file location and are not stored in the participant system. For files that fail validation checks, the participant system generates a File Validation Report (FVR), including a rejection code, and then transmits the FVR to the bank s payment system using a file validation location. The IPF is also stored in the participant system file catalogue as an invalid file. In the participant system, one or more erroneous payment instruction causes the rejection of the entire file. The participant system does, however, attempt to verify all payment instructions within a file. The validation process, therefore, does not stop after the first erroneous payment instruction. Sender s File References (SFR) may be re-used until an IPF with that SFR is accepted as valid. Full details of duplicate and validation checks performed are available in reference [1]. Following validation and storage, IPFs received via the file interface are transmitted to the STEP2 central system in an identical manner to IPFs created from payment instructions received via the single payment interface (see section 4.1). The STEP2 central system validates all files it receives against a set of validation rules defined in reference [1]. The STEP2 central system automatically transmits the results of this validation process to the participant system in a File Validation Report (FVR). The processing performed by the participant system depends upon the type of FVR received, e.g. successful validation, partial rejection, or complete rejection: Upon receipt of a FVR indicating successful validation of an IPF received via the file interface, the participant system stores the FVR and updates the internal status of the IPF and the payment instructions within the FVR to reflect their validation by the STEP2 central system. The FVR is transmitted to the bank s payment system via a file validation location if the participant system is configured to do so. Upon receipt of a FVR indicating partial rejection of the IPF, the state of the invalid payment instructions received within the FVR are updated in the participant system to reflect the success or failure of their validation by the STEP2 central system. The FVR is transmitted to the bank s payment system via a file validation location. Upon receipt of a FVR indicating complete rejection of the IPF, the state of the relevant IPF in the participant system file catalogue is updated and the state of all the payment instructions received within that IPF are also updated to reflect their rejection by the STEP2 central system. The FVR is transmitted to the bank s payment system via a file validation location. 25