STEP2 – Pan-European Bulk Payment Processing

System

Functional Overview

Final 3v1 of 11th September 2006

1

2

Contents

1 Introduction ..................................................................................................4 1.1 References ........................................................................................................4 1.2 Modification History ...........................................................................................4

2 The Scope Of The STEP2 Service ....................................................................5 2.1 General Service Description ................................................................................5 2.2 The Phase One Cross Border € Credit Transfer Service.........................................6

3 STEP2 Operation ...........................................................................................7 3.1 Overview...........................................................................................................7 3.2 Input Files & Validation ......................................................................................9 3.3 STEP2 Routing................................................................................................. 10

3.3.1 Routing Tables.......................................................................................................10 3.3.2 The Routing Process...............................................................................................11

3.4 The Daily Cycle................................................................................................ 12 3.5 Settlement in EURO1/STEP1............................................................................. 14 3.6 Settlement Files............................................................................................... 15 3.7 Reconciliation Files........................................................................................... 15

3.7.1 Daily Reconciliation Report (DRR)............................................................................16 3.7.2 Monthly Statistics Report (MSR) ..............................................................................17

3.8 Enquiries......................................................................................................... 18 3.8.1 Tracking the status of input and output files.............................................................18 3.8.2 Tracking the status of payment instructions .............................................................19 3.8.3 Routing table information .......................................................................................19

3.9 Phase One STEP2 Implementation .................................................................... 20

4 STEP2 Participant System............................................................................. 22 4.1 Receiving Payment Instructions Via The Single Message Interface ...................... 23 4.2 Receiving Payment Instructions Via The File Interface........................................ 25 4.3 Receiving Settlement Results From The STEP2 Central System ........................... 26

4.3.1 Settled Payment Files (SPF) ....................................................................................26 4.3.2 Cancelled Payment Files (CPF) ................................................................................26

4.4 Receiving Reconciliation And Statistical Information From STEP2 ........................ 26 4.5 Local Management Interface ............................................................................ 27 4.6 Access To The Participant System Repository .................................................... 27 4.7 Physical Implementation (EBA-MPS) ................................................................. 28

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

1.0 21/06/2002 First Draft

1.2 27/09/2002 Re-work following agreement of functional specifications and interface specification.

1.3 9/10/2002 Internal review with EBA / SIA

1.4

1.5

10/10/2002

24/11/2004

FINAL version 1v4 October 2002

DRAFT 3v0 October 2004: New Logo; New Settlement Cut-off time; Compressed files functionality

3.1 11/06/2006 Draft 3v1 September 2006: Resending cancellations functionality

2 The Scope Of The STEP2 Service

2.1 General Service Description

STEP2 Pan-EuropeanBulk Payment

Processing Service

Sending STEP2Participant Bank

Receiving STEP2Participant Bank

Payments forprocessing in files

Processedpayments in files

External SettlementMechanism

Settlement obligations resultingfrom STEP2 processing

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

2.2 The Phase One Cross Border € Credit Transfer Service

STEP2CentralSystem

SendingDirect Participant

ReceivingDirect Participant

EURO1 / STEP1

Settlement obligations resultingfrom STEP2 processing

Payments forprocessing

in files

Processedpayments

in files

Payments forprocessing

from orderingbanks

Processedpayments forbeneficiary

banks

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

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.

Scope of the STEP2 ServiceOrdering Indirect

Participant OrOrdering

Non-ParticipantBeneficiary

Indirect Participant

Beneficiary Non-participantvia Receiving Direct Participantas nominated Preferred Agentof Sending Direct Participant

Sending / OrderingDirect Participant

Receiving / BenficiaryDirect Participant

STEP2CentralSystem

EURO1/STEP1

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 3.2.

7

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].

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].

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.

3.3.1 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 participantBIC-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.

Preferred Agent Direct participant 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.

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.

RoutePayment

57A isa DP?

Receiver =57AY Stop

57A isan IP?

N

Receiver = DPof 57AY Stop

Receiver =preferredagent of

sending DP

N

Stop

Figure 3-2 Routing process

11

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.

SendingDirect Participant

ReceivingDirect Participant

STEP2CentralSystem

16, 7

2, 5, 7

STEP1/EURO1

3 4

Figure 3-3 Central System Information Flow

# Stage Processing

1 Transmission of IPFs To STEP2

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.

2 Transmission of FVR To Sending Direct Participant

The STEP2 central system validates each file and responds with one and only one File Validation Report (FVR).

3 Transmission of Settlement Instructions to STEP1/EURO1

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.

4 Reception of Settlement Responses from STEP1/EURO1

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 cut-off 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.

5 Transmission of CPFs To Direct Participants (in rare cases)

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.

6 Transmission of SPFs To 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.

7 Transmission of Reconciliation Reports To 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

1

Opening Sending Cut-Off Settlement Setlement Cut-Off

Calculation ofBilateral Gross

Balances

Preparation ofSettlementInstructions

Transmission ofSettlementInstructions

File ValidationTransaction Validation

FVR TransmissionPayment Sorting

10.00 22.00

Reception ofSettlementResponses

Receiving File

Preparation of SettledPayment Files (SPF)

Preparation of DailyReconciliation

Reports (DRR) /Monthly Statistics

Reports (MSR)

Transmission ofOutput Files &

Reports

06.30 08.00

Day D-1 Day D

Preparation ofCancelled Payment

Files (CPF)

These processes performedfor each file received from adirect participant

2

3

4

5, 6, 7

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.

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].

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.

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.

3.7.2 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;

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.

3.8.1 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.

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.

3.8.3 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.

3.9 Phase One STEP2 Implementation

The phase one STEP2 physical implementation is shown in Figure 3-5, below.

Disaster Recovery Systems

SecureNetworks

STEP2BusinessControl

EURO1 /STEP1

STEP2 CentralProcessing System

OperationalControl

Help Desk

ABE EBA

SecureNetworks

Ordering Bank / STEP2Indirect Participant

Payment System(s)

ParticipantSystem

(optional)

Payment System(s)

STEP2 Direct Participant

Local Management Interface

BackOffice

EURO1/STEP1BusinessControl

WebstationInterface

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 fibre-optic 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 Service

SWIFTNet InterAct & FileAct Secure file transfer

SWIFTNet InterAct and Browse Secure browsing

SIANet File transfer service Secure file transfer

SIANet IP service 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.

4 STEP2 Participant System

The STEP2 participant system developed by SIA for the EBA is shown in Figure 4-1, below.

Repository Access

Direct Participant

STEP2CentralSystem

EBAParticipantSystem Files of

paymentinstructionsvia a secure

network

Payment System

Payment System

Floppy disk /CD ROM

MS SQL Server2000 Views

MQ Series

OfflineMedia

FTP

Single Payment Interface

File Interface

Local CommandInterface

BrowserPrintingFacilities

DatabaseApplication

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 4.4.

22

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 4.7.

4.1 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 Action

52A 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 9th character).

57A 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 9th character).

Table 4-1 Single Payment Interface To IPF Body Mapping Exceptions

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 cross-border, 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.

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.

26

4.3 Receiving Settlement Results From The STEP2 Central System

The STEP central system transmits settlement results in Settled Payment Files (SPF) and Cancelled Payment Files (CPF). Direct participants can choose to receive SPF and CPF in compressed or uncompressed format.

4.3.1 Settled Payment Files (SPF)

The STEP2 central system can be configured to transmit one SPF containing all settled payment instructions for which the direct participant is receiver, or three SPFs containing payment instructions where the direct participant is receiving the payment instructions as beneficiary bank, on behalf of indirect participants, or as preferred agent.

The participant system can be configured to transmit payment instructions received in SPFs via the file interface or the single message interface.

When configured to output SPFs via the file interface, SPFs are transmitted to the bank’s payment systems via locations configured for SPFs. Three locations can be configured, one for each of the three possible types of SPF.

When configured to output SPFs via the single message interface, the payment instructions in the SPF are mapped to single payment instructions before being transmitted to the bank’s payment systems. The single payment instructions are constructed in SWIFT FIN format to include blocks 1, 2, 3, and 4 with fields that can be correctly interpreted by a payment system. The exact details of the mapping performed are provided in reference [1]. Settled payment instructions can also be output to specific settlement payment instruction output queues by beneficiary bank. A default output queue is also defined for payment instructions destined for beneficiary banks for which no specific output queue is defined.

4.3.2 Cancelled Payment Files (CPF)

CPFs are only transmitted in the rare circumstances that payment instructions have been cancelled. A CPF is related to payment instructions from one and only one Input Payment File (IPF). The processing of a CPF depends upon the origin of the IPF to which it relates. CPFs for IPFs that originated via the participant system file interface are output via a CPF location in the participant system file interface. CPFs for IPFs that were constructed from payment instructions received via the single message interface are output in MT103 format via a cancelled payment queue in the single message interface. Before transmission, CPFs fields and blocks are mapped to match the structure of the original incoming message; the details of the mappings performed are provided in reference [1]

4.4 Receiving Reconciliation And Statistical Information From STEP2

Reconciliation information in the form of Daily Reconciliation Reports (DRR) and Monthly Statistics Reports (MSR) is transmitted periodically by the STEP2 central system. Direct participants can choose to receive DRR and MSR in compressed or uncompressed format.

The participant system can be configured to output reconciliation information and statistical information it receives via the file interface. If configured to do so, these files are output via a DRR location and MSR location.

DRRs and MSRs are also stored in the payment system for future reference.

27

4.5 Local Management Interface

A local management interface is provided that provides facilities for:

Starting and stopping the system,

Creating archives,

Manually controlling the transmission of files and payment instructions to the STEP2 central system and to bank’s payment systems,

Configuring the participant system, and

Enquiring on data files and payment instructions held on the participant system.

The participant system also generates an audit trail of all significant processing events. This audit trail can be viewed via the local management interface.

Information about errors detected by the participant is written to an event log.

The local management interface is browser-based, and local printing facilities can be used to generate printouts of reports, etc.

For security purposes, the local management interface implements three tiers of user, each access to a different range of commands.

Full information on the facilities available via the local management interface is provided in reference [1].

4.6 Access To The Participant System Repository

The contents of the participant system repositories are available to bank applications via database views. Information is accessible on the status of:

Payment instructions,

Input Payment Files (IPF),

File Validation Reports (FVR), and

Cancelled Payment Files (CPF).

In addition, real-time events generated via the participant system (in response to a file being transmitted, etc) are available via standard tools.

A full description of the information available to applications from the participant system is provided in reference [1].

28

4.7 Physical Implementation (EBA-MPS)

The STEP2 participant system is implemented as a stand-alone application on the Microsoft Windows 2000 Server platform. Interfaces are provided to the following networks for connection to the STEP2 central system:

SWIFTNet via SAG,

SWIFTNet via SNL, and

SIANet via FEMSI.

The STEP2 participant system can be integrated into the bank’s security infrastructure using the Windows 2000 security facilities.

EBA-MPS is available as a software application for installation and configuration by the bank.

Participant systems providing broadly similar functionality to EBA-MPS, but based on other platforms such as IBM mainframes, may also be available from SIA or other vendors.

- End –