Technical Specifications

(1)

SWIFTRemit Directory 2.0

Technical Specifications

These technical specifications provide detailed information about the SWIFTRemit Directory. They include descriptions of records, fields, and flags in the uploadable and downloadable files.

23 September 2011

Messaging

(2)

Preface

Purpose of this document

This document provides the technical specifications of the SWIFTRemit Directory. The specifications contain the following information:

• an introduction to the Directory and the Directory application of the SWIFTRemit solution • a definition of the entities, the roles for the Directory

• a technical description of the data structures supporting the reference data of the participants • the rules and the usage guidelines for the upload and the download of the participants'

reference data

• some example of the coding for the data structures for the participants

Intended audience

This guide is for operators and reference data managers that perform business and administration tasks using the SWIFTRemit Directory application.

Significant changes

The following table lists the changes to the SWIFTRemit Directory related to release 2.0. This table does not include editorial changes that SWIFT may have made to improve the usability and comprehension of the document.

Addition of values in field PP.05 Payment Product Group for pension payment, modify or resend messages, and creditor validation capability

3.2.2, "PP Data Structure" on page 17 "List of values for PP.05" on page 21

Addition of one value in field PP.06 Service Level for the flash service level

3.2.2, "PP Data Structure" on page 17

Addition of values in field PD.05 Participant Type for settlement service provider

3.1.2, "PD Data Structure" on page 13

Related documentation

• SWIFTRemit Service Description • SWIFTRemit Integration Guide

• SWIFTRemit Implementing FileAct Headers

• SWIFTRemit - Standards MX Message Implementation Guidelines

• SWIFTRemit - Standards MX Message Implementation Guidelines Business Examples

Note Customers can find the latest version of most of these documents on swift.com > Support > Documentation. For more information, contact your SWIFT commercial manager.

(4)

1 About SWIFTRemit Directory

Description

The SWIFTRemit Directory contains the reference data of the participants of the SWIFTRemit solution. This directory identifies the participants to the solution, their processing capabilities, and their point of services. Participants provide and update themselves their data. SWIFT controls, stores, and publishes the data according to the SWIFT Directories monthly publication cycle.

Important The usage of this directory is restricted to the participants of the SWIFTRemit solution.

Purpose

The purpose of the SWIFTRemit Directory is to standardise and facilitate the files exchange between the participants to the solution. Accurate and up-to-date reference data helps the solution participants to build consistent and exhaustive payment instructions. The directory contributes to increase the overall service efficiency and the level of straight-through processing for remittances transactions.

1.1 Entities Definitions

1.1.1 Types of participants

Two types of participants

A participant is a SWIFT user registered to the SWIFTRemit solution and can either be a service participant or a participant's agent.

Service participant

A service participant is a SWIFT registered user subscribed to the SWIFTRemit solution. Only service participants have direct access to the SWIFTRemit Directory and are directly involved in the data collection and data publication process with SWIFT.

Code: SP

Participant's agent

A participant's agent is registered under the responsibility of the service participant and likewise for the SWIFTRemit Directory process.

Participant's agent reference data are provided and maintained by the service participant responsible for their registration.

Code: PA

(5)

1.1.2 Reference Data Manager

Role

The reference data manager is responsible for the data management. He handles the collection, the processing and the publication process of the reference data for the service.

1.1.3 Data Files

Four different data types

The data of the directory is a set of unique attributes qualifying a participant. The directory contains four reference data types:

Data types Code

Participant data PD

Product and processing capabilities data PP

Point of service data PS

Counterparties data MY

Participant data

The participant data helps to identify the other participants in the service with their respective relationship: service participant or participant's agent.

The attributes include items such as: • processing BIC of the participant • the person of contact

• the country of operation • or the network address

When relevant, it also includes the agent relationships with other participant

It helps the participants building and maintaining the routing and processing table for their counterparts in the solution.

Code: PD

Product and processing capabilities data

This data contains the products features and operating parameters supported by the participants of the solution.

The attributes include items such as the following product features: • the type of remittance product

• the service levels per product • the currencies

(6)

The attributes also include operating parameters such as: • upper limits: the maximum amount authorised by participant • the validity period of a transaction not credited

• the transaction notification options

The product and processing capabilities data facilitates the participants to establish service level agreement between counterparts.

It helps participants to build and maintain the tables of the agreed service with counterparts that they can propose to their customers. It also helps to populate the payments instructions

message with accurate data for a better straight-through processing rate. Some processing capabilities like the limits can also be used by the participants in their remittance transaction authorisation process, by checking payments instructions against the counterparts authorised limits.

Code: PP

Note The product and processing capabilities declared in the directory by a participant can differ from the one that they support with counterparts in the service as defined in their bilateral service level agreement.

For instance, a service participant may declare in the directory that they support the delivery notification feature to mobile phone but does not necessarily offer that feature to all participants in the service.

Point of service data

The point of service data identifies the physical location where customers can be serviced by participants for sending or receiving remittances. It can be for instance a bank branch or an automated teller machine (ATM).

The attributes also include operating parameters such as: • upper limits: the maximum amount authorised by participant • the validity period of a transaction not credited

• the transaction notification options Code: PS

Counterparties data

The counterparties data is the list of counterparties that a participant has in the service. The business contracts are between a participant identifier and his counterparties.

(7)

2 Working Model

Workflow D1040053 Reference Data Manager Service Participants Reference Data Manager Service Participants SWIFTRemit Directory on swift.com Data download - My data - My Counterparties - Full directory

Data entry Participants

data PD Points of Services PS Product and Processing capabilities PP Upload in .txt format Online data entry My counterparties MY My Counterparties My Data My counterparties MY Upload in .txt format Participants data PD Points of Services PS Product and Processing capabilities PP My Data

What the reference data manager can do

The reference data manager can provide data for: • his own institution - My Data

The reference data manager is responsible for the control and accuracy of the participant data.

The reference data manager can upload data for participants identifier BIC11 belonging to the hierarchy of the BIC code of his own institution.

If his BIC code is not the one of this parent institution, he can only upload data for the hierarchy below his own BIC.

(8)

He can only provide data for all BICs belonging to the parent institution if his swift.com e-mail address is linked to the parent BIC.

• the counterparties BICs - My Counterparties

This is the list of counterparties that a participant has in the service. The business contracts are between a participant identifier and his counterparties.

Prerequisite

To use the SWIFTRemit Directory application, you first need to subscribe to the SWIFTRemit Directory using the e-forms on swift.com. Separate e-forms are available for the test service or the live service.

Important During the subscription process, the participants are requested to assign a reference data manager.

Functions of the application

The SWIFTRemit Directory application has the following functions: • Templates • Upload • Status • Download • My Data Online • Help

2.1 Data Entry

Two options

You have two options to provide data: • Upload data in .txt format

In this case, you can use the Templates, Upload and Status functions

Note The Templates function provides you with templates in Microsoft Excel format to facilitate the upload process.

• Upload data online, using the My Data Online function

(9)

2.1.1 Upload Data in .txt Format

The Templates function

Use the Templates function if you want to use the Microsoft Excel templates to provide the following data:

• My Data: the data of your own institution – PD: participants' data

– PP: your own products and processing capabilities and the ones of your agents – PS: your own points of services and the one of your agents

• My Counterparties MY: the list of counterparties

The Microsoft Excel templates contain three macro buttons to perform the following tasks: • to import data

• to validate data

• to generate a .txt file, required for upload

The Upload function

Use the Upload function to upload the files PD, PP, PS and MY) in the directory. Once uploaded, the files are validated automatically by the directory application.

You can upload a file at any time during the month. • Before the cut-off time

Only the files uploaded and validated before the cut-off date of the month are guaranteed to be published for the current monthly publication cycle.

• After the cut-off time

Files uploaded after the cut-off date are left for the publication cycle of the following month. The cut-off date for SWIFTRemit Directory is in line with the cut-off date of the other SWIFT Directories.

The SWIFT Directories Publication Schedule is available on swift.com > Products & services > Messaging > Reference Data > Resources centre > Useful linksPublication Schedule.

When the participant data is modified, the reference data manager must not upload the entire data of the participant again. In this case, he can use a delta file containing only the modified, deleted, and new records.

The Status function

Use the Status function to verify the status of your upload tasks. In case of errors, click the link to consult the error message.

You must first correct the error before uploading the file again.

In case of syntax error, the file is rejected and the reference data manager is notified by e-mail.

Note Only the validated files are published.

(10)

2.1.2 Upload Data Online

The My Data Online function

Use the My Data Online function to update data record by record. This function is available for the PD, PP, and PS data types.

Existing records can also be modified using this function.

Note You can use the Help function at any time.

2.2 Data Download

The Download function

You can download three types of files from the SWIFTRemit Directory application: • My Counterparties: your published counterparties data

• My Data: your own data

• Full Directory: the entire published Workers Remittances Directories

Concepts

The data is always structured around the following concepts: • Data structure

– PD participant data

– PP: products and processing data – PS: point of services data

• Environment – Test – Live • Data content

– Full: contain all the records

– Delta: delta files contain only the records that have been modified since the previous publication.

Version of files

(11)

2.2.1 My Counterparties

Scope

Use My Counterparties to download in .txt format the data of your counterparties.

Data structure Data content

PD PP PS Full Delta

Test ✓ ✓ ✓

✓ ✓

Live ✓ ✓ ✓

Example

File naming convention of a PD file

Full Delta Test WR_PD_MY_TEST_DELTA_<Participant BIC8>_<Publication Date as yyyymmdd>.txt WR_PD_MY_TEST_DELTA_<Participant BIC8>_<Publication Date as yyyymmdd>.txt Live WR_PD_MY_<Participant BIC8>_<Publication Date as yyyymmdd>>.txt WR_PD_MY_DELTA_<Participant BIC8>_<Publication Date as yyyymmdd>>.txt

2.2.2 My Data

Scope

Use My Data to download in .txt format your own data.

Data structure Data content

PD PP PS Full Delta

Test ✓ ✓ ✓

✓ NA

Live ✓ ✓ ✓

Example

File naming convention of a PD file.

Full Delta

Test WR_PD_TEST_DELTA_<Participant BIC8>_<Date as yyyymmdd>.txt

NA

Live WR_PD_FULL_<Participant BIC8>_<Date as yyyymmdd>>.txt

NA

2.2.3 Full Directory

Scope

Use Full Directory to download in .txt format the data for the entire directory.

The files are available at the date of publication according the SWIFT Directories Publication Schedule (5 to 7 days after the cut-off date for upload),

(12)

Data structure Data content PD PP PS Full Delta Test ✓ ✓ ✓ ✓ ✓ Live ✓ ✓ ✓ Example

File naming convention of a PD file.

Full Delta

Test WR_PD_TEST_DELTA_<Activation Date as yyyymmdd>.txt

WR_PD_TEST_DELTA_<Activation Date as yyyymmdd>.txt

Live WR_PD_<Activation Date as yyyymmdd>>.txt

WR_PD_DELTA_<Activation Date as yyyymmdd>>.txt

(13)

3 Files

3.1 Participant Data

3.1.1 File Naming Convention

Filename for live PD data structure

WR_PD_DELTA_<Participant Identifier>_<Activation Date as yyyymmdd>>.txt

Filename for test PD data structure

WR_PD_TEST_DELTA_<Participant Identifier>_<Activation Date as yyyymmdd>.txt Examples Live: WR_PD_DELTA_SBZAZAJJ_20091001.txt Test: WR_PD_TEST_DELTA_SBZAZAJJ_20091001.txt

3.1.2 PD Data Structure

Field descriptions

Record's unique identifier: PARTICIPANT IDENTIFIER (PD.03) + RELATIONSHIP BIC (PD.07)

Ref Field name Description Status Data type

Cardinality Max lengt h (in char) Mappin g PACS field(2)

Usage rules and guidelines

PD.00 RECORD KEY The unique key of the record in the file. The key consists of the ISO country code and a sequential number of 6 digits

M Alphanumeric

[1..1]

8 Participants must leave the field empty when they upload a new record

Participants must populate the field with the value assigned by SWIFT when uploading a record for modification

The format is <CC><NNNNNN> Where:

• <CC> is the ISO country code of the participant

• <NNNNNN> is a unique sequence number assigned by SWIFT directories.

PD.01 TAG Indicator of the type

of record

M Alphabetic

[1..1]

2 The file Identifier tag value for a PD file is PD.

(14)

Ref Field name Description Status Data type Cardinality Max lengt h (in char) Mappin g PACS field(2)

PD.02 MODIFICATION FLAG In the upload process: • modification flag as requested by the participant In the publication process: • State of the record for the current publication cycle compared to the previous publication cycle M Alphabetic [1..1]

1 In the upload process

• A addition request

• M modification request

• D deletion request In the publication process

• A Added record • M Modified record • D Deleted record (3) • U unchanged record PD.03 PARTICIPANT IDENTIFIER Identifier of a participant in the service M Alphanumeric [1..1]

11 yes Used as part of the key in the data structure to identify a participant to the service and the PD file in particular. In the case of service participant PD.05="S" the value must be a BIC8 or a BIC11.

In the case of a participant agent PD.05="A" the value must be a BIC or a proprietary identifier with less than 11 characters Used to identify FI in the pacs messages acting in the payment/ settlement process as debtor agent, creditor agent and intermediaries like Instructed/ instructing Agent, Instructing/ instructed Reimbursement Agent, Third Reimbursement Agent (see pacs structures). PD.04 PARTICIPANT NAME Name of the participant M Alphanumeric [1..1]

70 yes Used to identify the name of the participant for the administration of the service.

PD.05 PARTICIPANT TYPE

Participant type can be either SERVICE or AGENT

according the participation criteria defined for the

SWIFTRemit Service Description

M Alphabetic

[1..1]

1 Value="S" if the participant acts as a service participant.

Value="A" if the participant acts as agent of service participant. Value="P" if the participant acts as settlement service provider Value="M" if the participant acts

(15)

PD.06 SWIFT USER CATEGORY

The field must be present and must reflect the SWIFT user category(1)

M Alphanumeric

[1..1]

4 The service participant should

indicate in that field the type of membership that they have as a SWIFT user.

See the Eligibility Criteria section of the SWIFTRemit Service

Description.

PD.07 RELATIONSHIP BIC

That field defines the relationship with a service

participant. In the case that the Participant is an AGENT, the field must link with the BIC8 of the registering participant

M BICIdentifier [1..1]

11 One AGENT can have several

relationships with SERVICE. Nevertheless a participant must create a record for each of its agent even if already registered with another participant If the PARTICIPANT TYPE is SERVICE, then the relationship BIC must be equal to the BIC of the participant identifier in PD.03.

PD.08 CITY Name of city or

place of the

participant operation for the service

M Max35Text

[1..1]

35 yes Used to identify the city of the participant for the administration of the service.

PD.09 COUNTRY

CODE

ISO country code of the participant operation for the service

M CountryCode

[1..1]

2 yes Used to identify the country of operation of the participant for the administration of the service.

PD.10 ADDRESS Building name,

detailed building information, street name, and number. The order of the information in these 4 fields depends on accepted practice for the individual country (part1)

M Max70Text

[1..1]

70 yes Used to identify the address of operation of the participant for the administration of the service.

PD.11 POSTCODE Address of the participant operation

M Max16Text

[1..1]

16 yes Used to identify the participant post code and location for the administration of the service. PD.12 SUBSCRIPTION

DATE

Date from which the entry is valid (defined as the initial operational date from the service subscription/ renewal date) M Date (YYYYMMDD ) [1..1]

8 Date of subscription of the

SWIFT user to the service Date fields have a length of 8 characters, structured in this format YYYYMMDD, where: • YYYY = year • MM = month • DD = day Files

(16)

PD.13 EXPIRATION DATE

Date up to which the entry is valid (defined as the end of operational date from the initial service subscription/ renewal date) O Date (YYYYMMDD ) [1..1]

8 Date of expiration of the

subscription of the SWIFT user to the service.

PD.14 CONTACT

NAME 1

Name of the person of contact within the organisation of the participant in charge of the relationship with SWIFT M Alphanumeric [1..1]

70 For service participant, the person described must be the reference data manager.

PD.15 CONTACT

PHONE 1

Phone of the contact person (See field PD.09) M Alphanumeric (4) [1..1] 70 PD.16 CONTACT E-MAIL 1

E-mail of the contact person (See field PD.09) M Alphanumeric [1..1] 70 PD.17 CONTACT NAME 2

Name of the person of contact within the organisation of the participant in charge of the relationship with SWIFT for the service O Alphanumeric [1..1] 70 PD.18 CONTACT PHONE 2 Phone of the contact person (See field PD.09) O Alphanumeric (4) [1..1] 70 PD.19 CONTACT E-MAIL 2

E-mail of the contact person (See field PD.09) O Alphanumeric [1..1] 70 PD.20 SWIFTNET ADDRESS The SWIFTNet address or Distinguished Name (DN) that the participant will be using the exchange FileAct messages with counterparts in the service M Max70Text [1..1] 70

(1) For more information about user categories, see swift.com > about SWIFT > Community > SWIFT user categories

(2) pacs002/004/008

(17)

3.2 Product and Processing Data

3.2.1 File Naming Convention

Processing rule

The files are processed as incremental updates.

Filename for live PP data structure

WR_PP_DELTA_<Participant Identifier>_<activation date as yyyymmdd>.txt

Filename for test PP data structure

WR_PP_TEST_DELTA_<Participant Identifier>_<activation date as yyyymmdd>.txt Examples Live: WR_PP_DELTA_SBZAZAJJ_20091001.txt Test: WR_PP_TEST_DELTA_SBZAZAJJ_20091001.txt

3.2.2 PP Data Structure

Record's unique identifier:

PARTICIPANT IDENTIFIER (PP.03) + PARTICIPANT RELATIONSHIP BIC (PP.04) + PAYMENT PRODUCT GROUP (PP.05) + SERVICE LEVEL (PP.06) + PROCESSED CURRENCY (PP.07). See 4.2.1, "Records Relationship and Uniqueness"

Cardinality Max lengt h (in char) Mappin g on PACS(1) field

PP.00 RECORD KEY The unique key of the record in the file. The key consists of the ISO country code and a sequential number of 6 digits

M Alphanumeric

[1..1]

8 Participants must leave the field empty when they upload a new record

Participants must populate the field with the value assigned by SWIFT when uploading a record for modification or deletion The format is: <CC><NNNNNN> where <CC> is the ISO country code of the participant and <NNNNNN> is a unique sequence number assigned by SWIFT directories.

PP.01 TAG Indicator of the type

of record for the service

M Alphabetic

[1..1]

2 The file Identifier tag value for a PP file is PP.

(18)

Ref Field name Description Status Data type Cardinality Max lengt h (in char) Mappin g on PACS(1) field

PP.02 MODIFICATION FLAG In the upload process: modification flag as requested by the participant In the publication process: State of the record for the current publication cycle compared to the previous publication cycle M Alphabetic [1..1]

1 In the upload process:

• A addition request

• M modification request

• D deletion request

• U unchanged

In the publication process:

• A Added record • M Modified record • D Deleted record(2) • U Unchanged record PP.03 PARTICIPANT IDENTIFIER Identifier of a participant in the service M Alphanumeric [1..1]

11 yes Should relate to the participant identifier (PD.03) in the PD file having registered the product and processing capabilities. PP.04 PARTICIPANT

RELATIONSHIP BIC

That field defines the relationship with a Service

Participant. In the case that the Participant is an AGENT, the field must link with the BIC8 of the registering participant

11 Should relate to the relationship BIC (PD.07 ) in the PD file having registered the product and processing capabilities.

PP.05 PAYMENT

PRODUCT GROUP

Code indicating payment product group within the service level under which payments can be executed by the participant. See the "List of values for PP.05" on page 21.

M Alphanumeric

[1..1]

4 This field must be completed with the list of the payment product categories supported for

processing by a participant in the service.

When creating payment instructions for a remittance transaction to a counterparty, the participants should make sure that they only indicate a payment product category supported by its counterparty.

(19)

PP.06 SERVICE LEVEL

Code indicating pre-agreed level of service under which payments can be executed by the institution. List of values limited to WR01, WR02, WR03, WR04 at the moment for SWIFTRemit Standard, Urgent, Instant , and Flash SLA(3) M Max4Text [1..1]

4 yes This field must be completed with the list of the service level supported by a participant in the service.

When creating payment instructions for a remittance transaction to a counterparty, the participants must make sure that they only indicate in the service level field a service level supported by its counterparty. The service level selected by the participant should be populated in the data structure ref 1.22 Service Level in the field Proprietary ref 1.24 (See pacs 008 structures for remittances).

PP.07 PROCESSED CURRENCY Currency per product category supported for processing by the participant M CurrencyCod e [1..1]

3 yes This field must be completed with a list of structured values

reflecting the currencies processed by a participant per product category in the service. When creating payment instructions for a remittance transaction to a counterparty, the participants must make sure that they only instruct a currency supported by its counterparty per product category as indicated in the list.

PP.08 RECEIVING UPPERLIMIT

Maximum value per payment that a receiving participant can authorise in the service scheme according their international/ regional obligations in the country of operation O Numeric [1..1]

8 yes This field must be completed with a list of structured values

reflecting the maximum amount processed by the participant per transaction, per currency and per product category in the service. When creating payment instructions for a remittance transaction to a counterparty, the participants should make sure that they only instruct an amount smaller or equal to the maximum amount supported by its

counterparty per product category and per currency as indicated in the list.

(20)

PP.09 MAXIMUM

VALIDITY DURATION

Maximum validity for a payment not credited to the beneficiary from the date of payment receipt by the receiving bank (number of business days) O Numeric [1..1]

3 yes Value must be set by the participants according their international/regional obligations in the country of operation if any. The reference data environment should provide the data structure to support the publication of data. In absence of specific national obligations, the following guidelines are recommended for transparency:

• For product group 1 (account based)

If a non-STP payment cannot be repaired, then it must be returned within 7 days by the creditor agent/ultimate creditor agent.

• For product group 2 (non-account based)

A transaction not delivered to the beneficiary should be returned by the creditor agent/ ultimate creditor agent after 45 days.

Operational usage: at each settlement cycle with its counterparties in the service, a check should be done by participants, acting as a creditor agent for the remittances payments not credited to beneficiaries is the current date is beyond number of business days from the settlement date for the creditor agent for the transaction. PP.10 CREDITOR NOTIFICATION OPTION Notification options supported by the participant towards creditor TEL, SMS, EMAIL, FAX, ADDRESS, HDEL O Max12text [1..6]

65 yes See code field (ref 2.47) in the instruction for creditor agent data structure (ref 2.46) in the pacs. 008 subset for the service. When creating payment instructions for a remittance transaction to a counterparty, the

(21)

PP.11 SETTLEMENT

TIME ZONE

Time zone of settlement for the participant

M Alphanumeric

[1..1]

10 Defined in reference to GMT. For example, the settlement time zone value for a participant in Paris would be GMT+01.00.

(1) pacs. 004

(2) a record marked as deleted is automatically removed from the publication file at the next publication cycle. (3) WR01, WR02, WR03 are payments processed in the swift.remit.fast FileAct store-and-forward service.

WR04 is for real-time payment processed in the swift.remit.flash FileAct real-time service.

List of values for PP.05

For PP.05, the list of values are limited to: • GRP1 account based remittance product • GRP2 non-account based remittance product

• GR1M account based remittance product with creditor account identified with mobile phone • GR2M non-account based remittance product with creditor identified with mobile phone only at

the moment

• CVL1 creditor validation capability for group 1 (creditor account details) • CVL2 creditor validation capability for group 2 (creditor identifier details)

• RSN1 modify by resend for product group 1 (modification of creditor account details) • RSN2 modify by resend for product group 2 (modification creditor identifier details) • MDF1 modify for product group 1 payment

• MDF2 modify for product group 2 payment

• PEN1 pension payment for product group 1 payment • PEN2 pension payment for product group 2 payment

3.3 Point of Services Data

3.3.1 File Naming Convention

Processing rule

The files are processed as incremental updates.

Filename for live PS data structure

WR_PS_DELTA_<Participant POS BIC>_<activation date as yyyymmdd>.txt

(22)

Filename for test PS data structure

WR_PS_TEST_DELTA_<Participant POS BIC>_<activation date as yyyymmdd>.txt Examples Live: WR_PS_DELTA_SBZAZAJJ_20091001.txt Test: WR_PS_TEST_DELTA_SBZAZAJJ_20091001.txt

3.3.2 PS Data Structure

Record's unique identifier: POS BIC (PS.03) + PROPRIETARY IDENTIFIER (PS.04 ) + OWNER IDENTIFIER (PS.05) + OWNER RELATIONSHIP BIC (PS.06). See 4.2.1, "Records Relationship and Uniqueness"

Cardinality Max lengt h (in char) Mappin g PACS(1) field

PS.00 RECORD KEY The unique key of the record in the file. The key consists of the ISO country code and a sequential number of 6 digits

M Alphanumeric

[1..1]

8 Participants must leave the field empty when they upload a new record.

Participants must populate the field with the value assigned by SWIFT when uploading a record for modification or deletion. The format is: <CC><NNNNNN> where <CC> is the ISO country code of the participant and <NNNNNN> is a unique sequence number assigned by SWIFT directories.

PS.01 TAG Indicator of the type

of record for the service

M Alphabetic

[1..1]

2 The file Identifier tag value for a PS file is PS. PS.02 MODIFICATION FLAG In the upload process: modification flag as requested by the participant in the publication process: State of the record for the current publication cycle compared to the previous publication cycle. M Alphabetic [1..1]

• A Addition request

• M Modification request

• D Deletion request In the publication process:

• A Added record

(23)

Ref Field name Description Status Data type Cardinality Max lengt h (in char) Mappin g PACS(1) field

PS.03 POS BIC BIC11 Code of the

PS (BIC11 used by the participant in the service to identify a branch in its retail network and enabled for the service)

O BIC11Identifie r

[1..1]

11 yes At least one of the 2 fields PS.03 or PS.04 must be filled. The value should be mapped on the Branch Identifier field of the Branch Identification Data Structure in the pacs. 008/004/002 subset for

remittances for debtor agent and creditor agent. PS.04 PROPRIETARY IDENTIFIER Proprietary Identifier of the PS (used when a participant has a special branch identifier) O(2) _Alphanumeric [1..1]

35 yes When the PS BIC code is not present, the Proprietary PS Identifier should be mapped on the Branch Identifier field of the Branch Identification Data Structure in the pacs. 008/004/002 subset for remittances from debtor agent and creditor agent.

PS.05 OWNER IDENTIFIER Identifier of the participant owner of the PS M Alphanumeric [1..1]

11 yes Should relate to the participant identifier (PD.03) in the PD file owner of the point of service.

PS.06 OWNER

RELATIONSHIP BIC

Defines the

relationship BIC with the service

participant owner of the POS

11 Should relate to the relationship BIC (PD.07) in the PD file owner of the point of service.

PS.07 NAME Name of the PS M Max35Text

[1..1]

35 yes To facilitate the straight-through processing, when PS.03 and PS. 04 are empty it is recommended to populate the value of that field in the Branch Name field of the Branch Identification data structure in the pacs. 008/004/002 subset for remittances.

PS.08 CITY Name of city or

place of the PS

M Max35Text

[1..1]

35 yes To facilitate the straight-through processing, when PS.03 and PS. 04 are empty it is recommended to populate the value of that field in the TownName field of the Branch Identification data structure in the pacs.08/004/002 subset for remittances.

PS.09 COUNTRY

CODE

ISO country code of the PS

O CountryCode

[1..1]

2 yes To facilitate the straight-through processing, when PS.03 and PS. 04 are empty it is recommended to populate the value of that field in the Country field of the Branch Identification data structure in the pacs.008/004/002 subset for remittances.

The Country code of a PS cannot be different from the Country Code declared by the participant owner of that PS in its PD record.

(24)

PS.10 ADDRESS Address of the PS M Max70Text

[1..1]

70 yes To facilitate the straight-through processing, when PS.03 and PS. 04 are empty it is recommended to populate the value of that field in the Street Name field of the Branch Identification data structure in the pacs.08/004/002 subset for remittances.

PS.11 POSTCODE Address of the institution head quarters (derived from the BIC Directory)

M Max16Text

[1..1]

16 yes To facilitate the straight-through processing, when PS.03 and PS. 04 are empty it is recommended to populate the value of that field in the PostCode field of the Branch Identification data structure in the pacs.08/004/002 message subset for remittances. PS.12 OPENING

HOURS MON

Business opening hours in the day (Monday)

O Max12Text

[0..3]

36 The business hours must be

coded with a begin time and an end time with 2 digits for hours and 2 digits for minutes with : as separator between hours and minutes and / as separator between begin time and end time.

hh:mm/hh:mm up to 3 time ranges can be defined for a day. For example, business hours from 8H30 to 16H30 are coded as <TAB>08:30/16:30<TAB> PS.13 OPENING

HOURS TUE

Business opening hours in the day (Tuesday) O Max12Text [0..3] 36 PS.14 OPENING HOURS WED Business opening hours in the day (Wednesday) O Max12Text [0..3] 36 PS.15 OPENING HOURS THU Business opening hours in the day (Thursday) O Max12Text [0..3] 36 PS.16 OPENING HOURS FRI Business opening hours in the day (Friday) O Max12Text [0..3] 36 PS.17 OPENING HOURS SAT Business opening hours in the day (Saturday) O Max12Text [0..3] 36 PS.18 OPENING HOURS SUN Business opening hours in the day (Sunday)

O Max12Text

[0..3]

(25)

PS.19 CONTACT

NAME 1

Name of the person of contact for the PS

O Alphanumeric

[1..1]

70 Fields provided by participants to their counterparties in sending or receiving countries to improve quality and transparency of service to customers (those fields are not transported with the pacs.008/004/002 message subset for remittances).

PS.20 CONTACT PHONE 1 Phone of the contact person (cfr field 12) O(3) _Alphanumeric [1..1] 70 PS.21 CONTACT E-MAIL 1

E-mail of the contact person (See field 12) O Alphanumeric [1..1] 70 PS.22 CONTACT NAME 2

Name of the person of contact for the PS

O Alphanumeric [1..1] 70 PS.23 CONTACT PHONE 2 Phone of the contact person (See field 12) O(3) _Alphanumeric [1..1] 70 PS.24 CONTACT E-MAIL 2

E-mail of the contact person (See field 12) O Alphanumeric [1..1] 70 PS.25 SUPPORTED LANGUAGES Identification of the languages supported by the PS to serve customers (coded with ISO country code)

O Max3Text

[1..n]

40 List of languages coded as a list 3-characters code from the ISO639-2 table. http://www.loc.gov/standards/ iso639-2/ISO-639-2_utf-8.txt. PS.26 OPERATION TIME ZONE Time zone of operation of the PS M Max10Text [1..1]

10 Defined in reference to GMT. For example, the time zone value for a PS in Brussels "GMT+01.00.

(1) pacs.008

(2) A record marked as deleted is automatically removed from the publication file at the next publication cycle. (3) International ITU format

3.4 Counterparties Data

3.4.1 File Naming Convention

Filename for live MY data structure

WR_MY_DELTA_<BIC8>_<ActivationDate>.txt

Filename for test MY data structure

WR_MY_TEST_DELTA_<BIC8>_<ActivationDate>.txt

Examples

Live: WR_MY_DELTA_SBZAZAJJ_20091001.txt Test: WR_MY_TEST_DELTA_SBZAZAJJ_20091001.txt

(26)

3.4.2 MY Data Structure

Fields descriptions

Cardinality

Max lengt h (in char)

MY.01 RECORD KEY The unique key of the record in the file.

M Alphanumeric

[1..1]

8 Participants must leave the field empty when they upload a new record.

Participants must populate the field with the value assigned by SWIFT when uploading a record for modification or deletion. The format is: <CC><NNNNNN> where <CC> is the ISO country code of the participant and <NNNNNN> is a unique sequence number assigned by SWIFT directories.

MY.02 TAG Indicator of the type of record for the service

M Alphabetic

[1..1]

2 The file Identifier tag value for a MY file is MY.

MY.03 MODIFICATION FLAG

In the upload process: modification flag as requested by the participant In the publication process: State of the record for the current publication cycle compared to the previous publication cycle. M Alphabetic [1..1]

• A Addition request

• M Modification request

• D Deletion request In the publication process:

• A Added record • M Modified record • D Deleted record • U Unchanged record MY.04 PARTICIPANT IDENTIFIER Identifier of a Service participant in the service M Alphanumeric [1..1]

11 For a service participant PD. 05=”S” the value must be a BIC8 or a BIC11. MY.05 COUNTERPAR TY IDENTIFIER Identifier of your Counterparties in the service M Alphanumeric [1..1]

11 The counterparties should be identified with the same value that is used in the PD file (Participant identifier). As counterparties are always service participant (PD.05=”S”) the value must be a BIC8 or a BIC11.

(27)

4 Guidelines and Rules

4.1 Working Assumptions

4.1.1 Data Accuracy

Rule

The data provided by the participants in the reference data structures (PD, PP, PS) must be accurate and reflect the exact status and the capabilities of the participant at the moment of publication.

4.1.2 Country of Operation for Participants

Rule and guideline for service participants

A service participant may operate the service in several countries. Participant must create one data structure per country of operation.

Entries should be created in the PD and PP files for each operation instance of a participant in a specific country.

Guideline for participant agents

A participant agent may only operate in one country, the country registered by its related service participant.

4.1.3 Service Conditions and the Published Data

Rule

The service conditions agreed between the service participants can be different from the reference data published by the service participants in the directory, reflecting the participant service capabilities at the time of publication. Service conditions agreed between the service participants must be based on published capabilities but are agreed in bilateral outside the service framework.

Example

It doesn't mean because a service participant indicates that it supports INSTANT service level that it has an agreement for that service level with all the other service participant registered for the service.

(28)

4.2 Population Rules and Guidelines

4.2.1 Records Relationship and Uniqueness

PD records

The participant file (PD) must contain only one record per Service Participant or Participant Agent.

A service participant or a participant agent record is identified by a unique key made up of 2 fields : PARTICIPANT IDENTIFIER PD.03 and RELATIONSHIP BIC PD.07.

• If a new PD record uploaded by a service participant contains a key value equal to an existing key of a PD record in the published PD file of the SWIFTRemit Directory it will be rejected.

• If a modified PD record uploaded by a service participant contains a key value that does not equal an existing key of a PD record in the published PD file of the SWIFTRemit Directory it will be rejected.

PP records

A service participant or a participant agent owns one or several product and processing records (PP), meaning that the pair of fields PARTICIPANT IDENTIFIER PP.03 and PARTICIPANT RELATIONSHIP BIC PP.04 must always contain a pair of values pointing to an existing record with unique key PD.03 + PD.07 in the published PD file of the SWIFTRemit Directory.

• If a new or modified PP record uploaded by a service participant contains values in the PP.03 and PP.04 fields that does not equal an existing key of a PD record in the published PD file of the SWIFTRemit Directory it will be rejected.

A product and processing (PP) record is identified by a unique key made up of the following 6 fields: PARTICIPANT IDENTIFIER (PP.03) + PARTICIPANT RELATIONSHIP BIC (PP.04) + PAYMENT PRODUCT GROUP (PP.05) + SERVICE LEVEL (PP.06) + PROCESSED CURRENCY (PP.07).

• If a new PP record uploaded by a service participant contains values equal to an existing key in the published PP file of the SWIFTRemit Directory it will be rejected.

• If a modified PP record uploaded by a service participant contains values not equal to an existing key in the published PP file of the SWIFTRemit Directory it will be rejected.

PS records

A service participant or a participant agent owns zero or several point of services records (PS), meaning that the pair of fields OWNER IDENTIFIER PS.05 and OWNER RELATIONSHIP BIC PS.06 must always contain a pair of values pointing to an existing record with unique key PD.03 + PD.07 in the published PS file of the SWIFTRemit Directory.

• If a new PS record uploaded by a service participant contains a key value in the PS.05 and PS.06 fields that does not equal an existing key of a PD record in the published PD file of the

(29)

A point of services (PS) record is identified by a unique key made up of the following 4 fields: POS BIC (PS.03) + PROPRIETARY IDENTIFIER (PS.04 ) + OWNER IDENTIFIER (PS.05) + OWNER RELATIONSHIP BIC (PS.06).

• If a new PS record uploaded by a service participant contains values equal to an existing record key in the published PS file of the SWIFTRemit Directory it will be rejected. • If a modified PS record uploaded by a service participant contains values not equal to an

existing record key in the published PP file of the SWIFTRemit Directory it will be rejected.

4.2.2 TAB Delimited Format

Rule

The data structures must be encoded in tab-delimited format (fields are delimited by <TAB> character and records by a Carriage Return/Line Feed character <CR/LF>.

Fields with multiple value should be delimited by <COMMA>.

4.2.3 Supported Character Set

Rule

The text fields of the data structure must only be populated with characters from the SWIFT II characters plus the @ character.

4.2.4 File Naming Conventions

Rule

The file naming conventions as described for the three data structures (participant data, product and processing capabilities, and point of services) must be followed by the service participant to insure consistency in processing by the SWIFT Service Administrator and their counterparties participating to the service.

Files submitted to the directory application with errors in the file naming convention will be rejected by the Service Administrator.

4.2.5 Submission Rule

Rule

The three participant files (participant data, product and processing capabilities, and point of services) must be created and uploaded in the SWIFTRemit Directory on swift.com before the cut-off date to be published the month after.

Related information

2, "Working Model"

(30)

4.2.6 Population Rules for Participant Agent

Rules

The service participants must register the details of the participants operating in the service, as their agent, under their responsibility.

The service participant must create and update the reference data files for their agents. A service participant can have several agents.

The service participants are responsible for the accuracy of the data provided for their participant agents.

The provided reference data must reflect the participant agent capabilities at the time of

publication. A participant agent could be registered by several service participants in the service with different product and processing capabilities and therefore a set of reference data files should be defined for each relationship of participant agent with a service participant.

4.2.7 Assignment of a Reference Data Manager by the

Participant

Rule

SWIFT recommends that service participants assign a reference data manager within its organisation to supervise the accuracy of the data provided in the files for the SWIFTRemit Directory.

The details of that person must be provided in the participant data structure and will be used by the SWIFT Service Administrator as the single point of contact for the participant concerning the SWIFTRemit Directory and related matters.

4.2.8 SWIFT Disclaimer on Participant Data Accuracy

Rule

The SWIFTRemit Directory service controls the syntax of the files but not the semantics. SWIFT is not liable for the data provided by the participants For example, the BIC field syntax provided by a participant can be correct in terms of format, but the BIC may be non-existing or expired.

4.2.9 Notification of Errors in Files to Participants

Rule

The SWIFTRemit Directory application notifies the rejection of a file to the contact person of the participant in case of processing error.

(31)

4.3.2 Selective Usage of Relevant Data by Participant

Rule

The participants must download from the swift.com the files that are relevant for their processing relationship (reference data of the counterparties for which they have a bilateral agreement to operate in the service) and have been updated if necessary since the last publication cycle (the file naming convention and the file creating date facilitate the relevant selection for the

participant).

4.3.3 In-house Database Update

Rule

When new relevant reference data have been downloaded by the participant, the participant must trigger a process for updating the in-house database used for processing the remittances transactions in the solution with the relevant data.

4.4 Fields Value Setting Rules and Guidelines

4.4.1 Participant Data

Rules

The publication of the participant data in the SWIFTRemit Directory is compulsory for all solution participants. The fields marked as mandatory in the participant data structure should be

populated by the participant and maintained accurate as long as the participant remains registered in the solution.

If the RELATIONSHIP BIC field PD.07 is equal to the BIC in the PARTICIPANT IDENTIFIER field PD.04 and if the PARTICIPANT TYPE field is S, the participant is a service participant. If the RELATIONSHIP BIC field is populated with the BIC of another participant, then the participant is agent of the service participant indicated in the RELATIONSHIP BIC.

If the PARTICIPANT IDENTIFIER field PP.03 is of BIC format then participant cannot be a service participant but a participant agent.

An agent is in relationship with one and only one service participant.

4.4.2 Point of Services Data

Rules and guidelines

The publication of point of services data in the Workers Remittance Directory is optional to the solution participant but highly recommended for non-account based products support in the service (Payment Product Group PP.05 equal to GRP2).

PS data can be related to one and only one participant (service participant or participant agent). The OWNER IDENTIFIER field PS.05 and the OWNER RELATIONSHIP BIC PS.06 of a PS record should relate to one unique participant record in the PD file with the same value populated in the PARTICIPANT IDENTIFIER field PD.03 and the RELATIONSHIP BIC field PD.07.

PS registered by a participant must be located in the same country as its owner participant. PS registered by a participant can be enabled for sending and/or receiving remittances services. PS

(32)

registered by a participant can be enabled for account and/or non-account product type (group 1 and group 2).

PS registered by a participant must support all service levels and currencies declared by participant in its PP record.

4.4.3 Product and Processing Capabilities

Rule

The publication roduct and processing data in the Workers Remittance Directory is mandatory for participant acting as receivers of remittances (creditor agent) and they must support at least one product set: type, service level, and currency. The publication PP data in the Remittance Directory is optional but highly recommended for participant acting only as sender of

remittances (debtor agent).

Although the fields of the PP data structure can take several values for the same participant, the combination of PARTICIPANT IDENTIFIER PP.03, PARTICIPANT RELATIONSHIP BIC PP. 04, Payment Product Group PP.05, Service Level PP.06, and Processed Currency PP.07form a unique key and set of value for remittance transaction and cannot be duplicated. See 4.2.1, "Records Relationship and Uniqueness".

Product and processing capabilities of a participant agent must be equal to, or a subset of, the capabilities declared by its owning service participant.

(33)

5 Examples of Data Structure Coding

5.1 PD Record

Narrative

Example of PD record coding for the Standard Bank of South Africa. File name value WR_PD_DELTA_SBZAZAJJ_20091001.txt

Header

RECORD KEY<TAB>TAG<TAB>MODIFICATION FLAG<TAB>PARTICIPANT

IDENTIFIER<TAB>PARTICIPANT NAME<TAB>PARTICIPANT TYPE<TAB>SWIFT USER CATEGORY<TAB>RELATIONSHIP BIC<TAB>CITY<TAB>COUNTRY

CODE<TAB>ADDRESS<TAB>POSTCODE<TAB>SUBSCRIPTION DATE<TAB>EXPIRATION DATE<TAB>CONTACT NAME 1<TAB>CONTACT PHONE 1<TAB>CONTACT E-MAIL 1<TAB>CONTACT NAME 2<TAB>CONTACT PHONE 2<TAB>CONTACT E-MAIL 2<TAB>SWIFTNET ADDRESS<TAB><CR/LF>

File

BE004444<TAB>PD<TAB>M<TAB>SBZAZAJJ<TAB>THE STANDARD BANK OF SOUTH AFRICA<TAB>S<TAB>MEMB<TAB>SBZAZAJJ<TAB>JOHANNESBURG<TAB>ZA<TAB>STANDAR D BANK CENTRE FLOOR 5 25 SAUER STREET

JOHANNESBURG<TAB>2001<TAB>20081001<TAB>20091001<TAB>VICKEY GANESH<TAB> +27116366832<TAB>[email protected]<TAB><TAB><TAB>DNXXXXX<T AB><CR/LF>

5.2 PP Record

Narrative

Example of PP record for Banco do Brazil acting as service participant supporting standard and urgent SLA, group1, and group 2 products, EUR/USD/BRL as processing currencies to be activated on 1 October 2009:

File name value WR_PP_DELTA_BRASBRRJ_20091001.txt

Header

RECORD KEY<TAB>TAG<TAB>MODIFICATION FLAG<TAB>PARTICIPANT

IDENTIFIER<TAB>PARTICIPANT RELATIONSHIP BIC<TAB>PAYMENT PRODUCT GROUP<TAB>SERVICE LEVEL<TAB>PROCESSED CURRENCIES<TAB>RECEIVING UPPERLIMIT<TAB>MAXIMUM VALIDITY DURATION<TAB>CREDITOR NOTIFICATION OPTION<TAB>SETTLEMENT TIME ZONE<TAB><CR/LF>

(34)

File <TAB>PP<TAB>A<TAB>BRASBRRJ<TAB>BRASBRRJ<TAB>GRP1<TAB>WR01<TAB>USD<TAB>10000<TA B>45<TAB>PHOB<TAB>GMT-03:00<TAB><CR/LF> <TAB>PP<TAB>A<TAB>BRASBRRJ<TAB>BRASBRRJ<TAB>GRP1<TAB>WR01<TAB>EUR<TAB>6000<TAB >45<TAB>PHOB<TAB>GMT-03:00<TAB><CR/LF> <TAB>PP<TAB>A<TAB>BRASBRRJ<TAB>BRASBRRJ<TAB>GRP1<TAB>WR01<TAB>BRL<TAB>30000<TA B>45<TAB>PHOB<TAB>GMT-03:00<TAB><CR/LF> <TAB>PP<TAB>A<TAB>BRASBRRJ<TAB>BRASBRRJ<TAB>GRP2<TAB>WR01<TAB>USD<TAB>5000<TAB >45<TAB>PHOB<TAB>GMT-03:00<TAB><CR/LF> <TAB>PP<TAB>A<TAB>BRASBRRJ<TAB>BRASBRRJ<TAB>GRP2<TAB>WR01<TAB>EUR<TAB>3000<TAB >45<TAB>PHOB<TAB>GMT-03:00<TAB><CR/LF> <TAB>PP<TAB>A<TAB>BRASBRRJ<TAB>BRASBRRJ<TAB>GRP2<TAB>WR01<TAB>BRL<TAB>15000<TA B>45<TAB>PHOB<TAB>GMT-03:00<TAB><CR/LF>

5.3 PS Record

Narrative

Example of a PS record of Banco do Brasil in Sao Paolo. File name value WR_PS_DELTA_BRASBRRJ _20081001.txt

Header

RECORD KEY<TAB>TAG<TAB>MODIFICATION FLAG<TAB>POS BIC<TAB>PROPRIETARY IDENTIFIER<TAB>OWNER IDENTIFIER<TAB>OWNER RELATIONSHIP

BIC<TAB>NAME<TAB>CITY<TAB>COUNTRY

CODE<TAB>ADDRESS<TAB>POSTCODE<TAB>OPENING HOURS MON<TAB>OPENING HOURS TUE<TAB>OPENING HOURS WED<TAB>OPENING HOURS THU<TAB>OPENING HOURS FRI<TAB>OPENING HOURS SAT<TAB>OPENING HOURS SUN<TAB>CONTACT NAME 1<TAB>CONTACT PHONE 1<TAB>CONTACT E-MAIL 1<TAB>CONTACT NAME 2<TAB>CONTACT PHONE 2<TAB>CONTACT E-MAIL 2<TAB>SUPPORTED LANGUAGES<TAB>OPERATION TIME ZONE<TAB><CR/LF>

File

BE004446<TAB>PS<TAB>M<TAB>BRASBRRJSBO<TAB><TAB>BRASBRRJ<TAB>BRASBRRJ<T AB>BANCO DO BRASIL<TAB>SAO PAULO<TAB>BR<TAB>RUE SAO BENTO

465<TAB>01011-100<TAB>09:00/19:00<TAB>ADOLFO ANGELO><TAB>

+551134913939<TAB>[email protected]><TAB>POR,ENG<TAB>GMT-03:00<TAB><CR /LF>

5.4 MY Record

Overview

The downloadable MY files contain a subset of the publication data for the participant's

counterparties. The PD, PP and PS have the same content described in previous examples. The only difference is that it does not contain the full data set.

(35)

Legal Notices

Copyright

You may copy this publication within your organisation. Any such copy must include these legal notices.

Confidentiality

This publication may contain SWIFT or third-party confidential information. Do not disclose this publication outside your organisation without the prior written consent of SWIFT.

Disclaimer

SWIFT supplies this publication for information purposes only. The information in this publication may change from time to time. You must always refer to the latest available version on www.swift.com.

Translations

The English version of SWIFT documentation is the only official version.

Trademarks

SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: SWIFT, the SWIFT logo, the Standards Forum logo, 3SKey, Innotribe, Sibos, SWIFTNet, SWIFTReady, and Accord. Other product, service, or company names in this publication are trade names, trademarks, or registered trademarks of their respective owners.

Technical Specifications

SWIFTRemit Directory 2.0