SWIFTReady Financial EAI

greasyservantInternet and Web Development

Jul 30, 2012 (5 years and 16 days ago)

1,779 views




SWIFTReady Financial EAI Label


Financial EAI Label


Criteria
2008

Copyright © S.W.I.F.T.

s.c.r.l.

All rights reserved.


Page
1














SWIFT
Ready
Financial EAI

Label criteria 200
8



Version

4

April

2008

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
2

Legal Notices

Copyright

Copyright © S.W.I.F.T. SCRL (“SWIFT”), avenue Adèle 1, B
-
1310 La Hulpe, Belgium, or its licensors,
2008
. All rights reserved.

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

Confidentiality

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

Disclaimer

The information in this publication may change from time to time. You must always refer to the latest
available version.

Translations

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

Trademar
ks

SWIFT, S.W.I.F.T., the SWIFT logo, Sibos, SWIFTNet, SWIFTAlliance, SWIFTStandards,
SWIFTReady, and Accord are trademarks of S.W.I.F.T. SCRL. Other SWIFT
-
derived service and
product names, including SWIFTSolutions, SWIFTWatch, and SWIFTSupport are traden
ames of
S.W.I.F.T. SCRL.

SWIFT is the trading name of S.W.I.F.T. SCRL.

Other product or company names in this publication are tradenames, trademarks, or registered
trademarks of their respective owners.



greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
3

Table of contents

1.

INTRODUCTION

................................
................................
................................
................................
...............................

4

P
URPOSE

................................
................................
................................
................................
................................
.................

4

A
UDIENCE

................................
................................
................................
................................
................................
................

4

SWIFTR
EADY
P
ROGRAMME
................................
................................
................................
................................
......................

4

2.

FINANCIAL EAI 2008

................................
................................
................................
................................
.......................

6

3. SWIFT MESSAGING P
ROTOCOLS

................................
................................
................................
................................
........

8

3.1

SWIFTN
ET
FIN

................................
................................
................................
................................
................................
..

8

3.2

SWIFTN
ET
I
NTER
A
CT

................................
................................
................................
................................
.........................

8

3.3

SWIFTN
ET
F
ILE
A
CT

................................
................................
................................
................................
...........................

9

4 STANDARDS

................................
................................
................................
................................
................................
.........

11

4.1

MT

................................
................................
................................
................................
................................
..................

11

4.2

ISO15022
................................
................................
................................
................................
................................
........

11

4.3

MX

................................
................................
................................
................................
................................
..................

12

4.4

ISO20022
................................
................................
................................
................................
................................
........

13

4.5

F
P
ML

................................
................................
................................
................................
................................
..............

13

4.6

SWIFTS
OLUTIONS

................................
................................
................................
................................
...........................

14

5. SWIFT CONNECTIVI
TY

................................
................................
................................
................................
.......................

15

5.1

SWIFTA
LLIANCE
A
CCESS
(SAA)

INTEGRATION

................................
................................
................................
...................

16

5.2

SWIFTA
LLIANCE
G
ATEWAY
(SAG)

INTEGRATION

................................
................................
................................
................

17

5.3

B
ACK
-
OFFICE INTEGRATION

................................
................................
................................
................................
...............

18

6

MESS
AGE VALIDATION

................................
................................
................................
................................
................

20

6.1

MT

M
ESSAGE
V
ALIDATION

................................
................................
................................
................................
.................

20

6.2

MX

M
ESSAGE
V
ALIDATION

................................
................................
................................
................................
................

22

6.3

G
IOVANNINI
F
ILE
T
RANSFER
R
ULE BOOK

................................
................................
................................
............................

23

7. REFERENCE DATA

................................
................................
................................
................................
..............................

24

7.1

BIC

I
NTEGRATION

................................
................................
................................
................................
.............................

24

7.2

BICP
LUS
IBAN

................................
................................
................................
................................
................................
.

24

7.3

SEPA

R
OUTING
D
IRECTORY

................................
................................
................................
................................
.............

25

7.4

MX

/

MT

D
IRECTORIES

................................
................................
................................
................................
......................

25

7.4

CIVIC

D
IRECTORY

................................
................................
................................
................................
............................

26

8. MESSAGE PROCESSIN
G

................................
................................
................................
................................
....................

26

8.1

M
ESSAGE
C
REATION

................................
................................
................................
................................
.........................

26

8.2

C
ONTENT
-
BASED
R
OUTING

................................
................................
................................
................................
................

26

8.3

R
ECEPTION FROM
SWIFT

................................
................................
................................
................................
.................

27

8.4

R
ECONCILIATION

................................
................................
................................
................................
...............................

27

8.5

M
ESSAGE
R
EPAIR AND
E
XCEPTION
H
ANDLING

................................
................................
................................
....................

28

8.6

D
UPLICATE AND
R
ETRY MANAGEMENT

................................
................................
................................
................................

28

8.7

E
VENT
L
OGGING

................................
................................
................................
................................
...............................

28

8.8

M
ESSAGE
A
RCHIVING

................................
................................
................................
................................
........................

28

8.9

M
ONITORING AND
S
UPERVISION

................................
................................
................................
................................
.........

29

8.10

MT/MX

TRANSLATION

................................
................................
................................
................................
.....................

29

M
ESSAGE PROCESSING RE
QUIREMENTS

................................
................................
................................
................................
...

29

9. USER

INTERFACE

................................
................................
................................
................................
................................

30

9.1

M
ESSAGE
V
IEWER

................................
................................
................................
................................
............................

30

9.2

M
ESSAGE
E
NTRY

................................
................................
................................
................................
..............................

30

9.3

M
ESSAGE
R
EPAIR

................................
................................
................................
................................
.............................

30

9.4

BIC

LOOK
-
UP

................................
................................
................................
................................
................................
....

30

9.5

B
USI
NESS
A
CTIVITY
M
ONITORING
(BAM)

................................
................................
................................
............................

30

9.6

U
SER
I
NTERFACE REQUIREMENT
S

................................
................................
................................
................................
......

31

10. MARKETING AND
SALES

................................
................................
................................
................................
................

31

11. LABEL 2008 SUMMA
RY

................................
................................
................................
................................
.....................

32

ANNEX A


MT

MESSAGES TO SUPPORT

................................
................................
................................
.............................

37


greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
4

1.

Introduction

Purpose

Throughout the years,
SWIFT developed
SWIFTReady
label programme to certify third party
applications and middleware products that support SWIFT messaging systems and standards an
d that
integrate with SWIFTNet using SWIFTAlliance interfaces.

This paper focuses

on

the

SWIFTReady
Financial EAI label, and provides an overview of the criteria
that an EAI must comply with to be granted a label from SWIFT.

Audience

The
target audience

f
or this document
is both
integration technology
v
endors
considering the
certification of their
EAI/
B2B
/SOA

suite, and SWIFT Users that look

after

an overview of the Financial
EAI Label contents. The audience shoul
d be familiar with SWIFT world
from

a
techn
ical and

a

business
outlook
.

SWIFTReady Programme

The
SWIFTReady
label
program
me

spans through the whole financial application
chain
,
and includes
Trade, Treasury, Payment
, ERP
, Corporate

and Securities

applications
.

Each
SWIFTReady
label defines a set of

criteria that
is

reviewed every year to ensure
that
the
software

remains
aligned

with
financial market
evolution and customer
needs
.

These
criteria

are designed to reflect the capability of
vendor

product
s

to provide

message processing

automation in a SW
IFT
context
, and
to
support Straight through

Processing (STP)

in order

to increase
customer value
, and reduce time to market.

The SWIFTReady Financial Enterprise Application Integration (EAI) Label
was

created in 2000 to ensure
the
proper
orchestration
of
data flows and business transaction
s

between back
-
office applications and
SWIFT Interfaces

deployed

at Financial Institution
s

(
FI
)
and
corporate

customers.

SWIFT customers are
more and more looking in generalised B2B services, requi
ring standardisation of end
-
to
-
end business
processes, such as payment transaction across the whole chain of participants.

EAI

refers to the combination of processes,
software,

standards and hardware resulting in
the
integration of

enterprise systems and

d
i
sparate corporate entities

to permit
single business
transaction
s

across multiple systems.

The
Financial EAI

more particularly
focuses on

the
specific
needs
of

the financial community,
including actors such as
banks, brokers, fund mangers, traders,
bankin
g and securities
market
infrastructures
and corporate treasury

department
s
.

The Financial
EAI maps

data coming from
business

applications into messages and files
that are
ready to be supplied to
any
f
inancial counterparty through
SWIFT interface
s.

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
5













Financial EAI involves the following
components
:

A Financial EAI
can

be decomposed in several logical building blocks:



Business Process
es

&
Workflow Engi
ne
:
the

EAI kernel
copes with message
s

and

file
s

creation,
mapping,
validation, storage, routing,

enrichment,
exception handling, sending to SWIFT
,
parsing

and reconciliation based on

SWIFT

A
cknowledgment

(
A
CK
)

and
Delivery

Notifications

(
DelN
)

from counterparty
.

It implements business rules for
financi
al

transactions.

It also support
s

S
tandard
Business
Messages
using
a data

dictionary
approach, which

is
built on
to

ISO15022 and
ISO20022
standards
.



Application Adapters
:
this includes technical adapters to back
-
office application
s

(adapter to
databases, a
pplications and file systems using .Net,
JMS, SOAP
,WS

or other protocols
), and the
b
usiness data
transformation

into the
required format (XML, FIN
, FpML
)

possibly
using
out
-
of
-
the
-
shelf
messaging
data services
.
The
p
roper message

header
s

are

created, based

on information
communicated by business application
s

and by
B2B partner
profile
s
.



User Interface
s
:
business flows need to be managed to deal with exception, message
entry
,
enrichment

and
repair
, reference data look
-
up (BIC
, IBAN, ISIN, SEPA Routing Direct
ories
),
and
Business Activity M
onitoring

(
BAM
).



SWIFT
Adapter
s
:
a
dapters to SWIFTAlliance Access and Gateway

interfaces

including
reconciliation

mechanisms.



Repositories
:
messages and events need

to be recorded for audit
and busine
ss process
management

purpose
. In addition,
resilient
a
ccess to reference data (B
IC,
IBAN,
IS
I
N,
CIVIC
and
Partners
profile)
, business rules and meta
-
data is required.


Repositories
Business Process
Workflow
User Interface
SWIFT
Adapters
Application
Adapters
Business
Application
SWIFT
Interfaces
Financial EAI
Repositories
Business Process
Workflow
User Interface
SWIFT
Adapters
Application
Adapters
Business
Application
SWIFT
Interfaces
Financial EAI
greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
6

2.

Financial EAI
2008


2
.1 Dimensions

The Financia
l EAI Label focuses on

features frequen
tly requested
by SWIFT Users. These have been
gathered into several dimensions:

1.

Messaging Protocols

required to handle messaging, envelope wrapping, security and routing

2.

Standards

support, including

SWIFTStandards (FIN, MX), industry (FpML)
and

proprietary

3.

SWIFT Connectivity
, involvin
g File, MQSeries or API based
adapters to SWIFT Interfaces

4.

Reference Data

access to
enrich
and repair messages for validation and
STP
compliance


5.

Message Processing
, including routing, exception handlin
g,
translation,
repair
,
enrichment

and
transaction management

6.

Message Validation

against SWIFTStandards and messaging protocols
.

7.

User Interface
s

to manage messaging flows, monitor alarms
, edit
, enrich

and

repair messages
.

8.

Marketing

and Sales

collaboration
requirements
.















Throughout the years, The SWIFTReady Financial EAI Label has been expanding along these
dimensions.
This document describes the EAI dimension features

for

SWIFTReady Label, and
provides

a

roadmap for future extensions.



2
.2 Ne
w requirements in
2008

To qualify for
the SWIFTReady Financial EAI label
,
a vendor product

must comply with a set of
mandatory criteria which are
described

in the
next

sections
.

The requirements that are
new in
2008

are summarised in the
below

synopsis

and

are
marked in light blue in subsequent sections
.
The
last column
list
s

all
o
ptional
requirements

(new or not) that
may be

supported
in

2008
.

These
will
not

Standards
Protocols
Connectivity
Reference Data
User Interface
Marketing&Sales
Routing
Reconciliation
Exception Handling
BPM
Processing
BIC
Msg Browse
BAM
AFT
MQSA
FTA
MT
ISO15022
ISO20022 (DD)
FpML
MQHA or
HQ Show
Press Release
Case Study
Sales2Sales
Re
-
selling
Map
Syntax Check
Network rules
Validation
FIN
MX
XML
Usage Rules
STP Guidelines
Securities Market Practices
Msg Repair
Msg Entry
InterAct RT
FileAct RT
InterAct S
&
F
FileAct S
&
F
Browse
Transaction Management
WSHA
MT
-
MX translating
5 Customers
Data Dictionary
Logging
BIC lookup
RAHA
BIC+
BIC Update Automation
SEPA Routing
SSI
IBAN
RMA
CIVIC
MX Rule Book
Payment Market Practices
Standards
Protocols
Connectivity
Reference Data
User Interface
Marketing&Sales
Routing
Reconciliation
Exception Handling
BPM
Processing
BIC
Msg Browse
BAM
AFT
MQSA
FTA
MT
ISO15022
ISO20022 (DD)
FpML
MQHA or
HQ Show
Press Release
Case Study
Sales2Sales
Re
-
selling
Map
Syntax Check
Network rules
Validation
FIN
MX
XML
Usage Rules
STP Guidelines
Securities Market Practices
Msg Repair
Msg Entry
InterAct RT
FileAct RT
InterAct S
&
F
FileAct S
&
F
Browse
Transaction Management
WSHA
MT
-
MX translating
5 Customers
Data Dictionary
Logging
BIC lookup
RAHA
BIC+
BIC Update Automation
SEPA Routing
SSI
IBAN
RMA
CIVIC
MX Rule Book
Payment Market Practices
greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
7

be mandated
for
the conferral of
EAI
label. Still, they
will be recognised
for the Partners

that
ca
n
demonstrate compliance
,

and
published
on
www.swift.com
, in

a
separate

sheet
of

the EAI label.



Finally, the presence of optional criteria in this document provides an indication o
n

how the
program
is
to
evolve
-

some of these optional criteria may become manda
tory in future releases
-

and should
therefore he
lp
EAI and B2B

vendors to plan for future evolutions of their products.

The complete list of EAI requirements for
2008

(new and old)
are summarised in
section
1
1

of this
document.




Dimension

Feature

New
EAI

Label Requirements

Optional Requirements

(new or not)

Messaging
Protocols

InterAct


InterAc
t support over SAG

FpML wrapping for
AI

FileAct

Support

SWIFTNet R6.1 and Bulk
Payments 2.0 rulebook for SEPA.

FileAct support over SAG
Giovannini
rulebook compliance (Euroclear CCI )

Standards

ISO
150022

SRG 2007

Use the ISO d
ictionary for internal data
representation

ISO
20022

SRG 2007

Use ISO 20022 to model business
transactions

FpML

Schema validation

FpML semantic validation

Connectivity

SAA

Upgrade and test with SAA6.0

SAA for FpML


SAG

Upgrade and test with SAG 6.1

WSHA for InterAct

RAHA/MQHA for InterAct and FileAct

Message
Validation

Market
Practices


Support all SMPG rules

Support ISO15022 Market Practices

MX


Validation against SWIFTSolutions
Rule Books

MT/MX coexistence support

Reference
Data

BICPlus

IBAN

Directory

BICPlus
IBAN Directory Support

BIC download automation

SEPA
Routing
Directory

SEPA Routing Directory Support


Message
Processing

Creation



Reconci
-
liation



Repair


Full Automated Repair for STP
compliance

Mapping


Convert Euroclear DEX
, Euclid and
E2A formats into ISO format

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
8

3.
SWIFT Messaging Protocols

SWIFT

provides

messaging

services
to
automate

structured financial information
transfer to business
partners
(SWIFTNet FIN and InterAct) and largest payload of structured
or

free format payload
(SWIFTNet FileAct).
A
n

F
inancial EAI should support
SWIFTNet FIN, InterAct a
nd FileAct
.

3
.1
SWIFTNet FIN

SWIFTNet FIN is a secure, reliable and resilient, access
-
controlled, structured
,

store
-
and
-
forward
messaging service. Value added processing includes message validation
against

SWIFTStandards,
delivery monitoring and prioritiza
tion,

on top of

central message storage and retrieval.

SWIFTNet FIN

supports more than 2
40

Message

Type
s

(
MT
)
categorised in
to

9
market segments

according to their
business usage (
Payment, Treasury,
FXMM
,
Derivatives,
Collections,
Sec
urities,
T
rade,
Precious Metals
and Cash

Management).

FIN

messages
can only be exchanged through a
SWIFT
qualified FIN Interface. The Financial EAI
should
at least
integrate with SWIFTAlliance

Access (
SA
A
) interface

using
Automated File Transfer
(AFT)
and
WebSphere MQ Series A
dapter (
MQSA
).

FIN messages are made of
data
blocks

for
addressing

and control

(block 1
to 3
),
MT business

payload
(block
4
) and
system
trailer
s

block

(bl
ock 5).

The Financial EAI should be able to generate and parse
all

FIN messages, including headers and trailer blocks.

SWIFTNet FIN messages

need to be reconciled at

different levels:

-

Local SAA
validation

against FIN header

(block 1 to 3)
, MT syntax and se
curity protocols


-

SWIFT Central Services

Acknowledgement

(
ACK
/
NAK
)

against Message Format Validation
Rules

(
MFVR
)

-

Reconciliation of Delivery Notification

(
DelN
)

provided by messaging counterparty


SWIFTReady Financial EAI Label criteria


The Financial EAI should support SWIFTNet FIN (correct headers, body and trailer
blocks generation) over SAA (AFT and MQSA) and should be able to par
se
incoming messages and reconcile them against any Notification level


3
.2
SWIFTNet InterAct

SWIFTNet InterAct
caters for

the interactive real
-
time and store
-
and
-
forward exchange of messages
between applications.
SWIFTNet
InterAct is widely used in
dive
rse
SWIFTSolutions
,
including

SWIFTNet
Funds, Exceptions
and

Investigations
, TSU, Proxy Voting,

FpML
and

Cash Reporting, and
for
M
arket Inititiatives

such as TARGET2
,

SEPA
, MiFID and Giovannini.

SW
IFTNet InterAct supports

any
XML

format

(
MX
, FpML,
and TSU
) and other structured formats (FIX)
wrapped into

X
ML envelope. SWIFTNet InterAct C
entral

S
ervices validate MX messages (
that are
XML messages designed using IS
O
20022


UNIFI

methodology)

and FpML messages
.

SWIFTNet InterAct can be used to send and receive business payload in real
-
time (
RT
) or
Store&Forward (
SF
) modes.


On acquiring a SF queue

from
SWIFT
Central

Services
, the requesting application select
s

either to
fetch messages using a client process (pull mode), or
to
use

a server to capture messages pushed by
the SF
central
queues (push mode).

Push mode is the preferred mode to
guarantee
throughput.


InterAct RT also allows to fetch data
from

a
counterparty server (
send request and get payload
greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
9

response), and to respond to data
queries
from
partners
.

SWIFTNet InterAct messages can be sent through SWIFTAlliance Access or SWIFTAlliance Gateway,
using on
e of the available adapters.

SAA accept
s

any XML format
, including

MX and FpML
.


SAA
provides a resilient
store
-
and
-
f
orward local messaging hub,
manage
s

the SWIFTNet protocol
(security, network and
SF

queues management)

and reconcil
iation process. These features are not
natively supported on SAG.
The following table displays the available SAG and SAA adapters for
every
SWIFTNet
InterAct function and mode.

SWIFTNet Inter
A
ct Adapters

Function

Mode

Server /
Client

SAA

AFT
or

MQSA

(1)

SA
G

RAHA

or
MQHA

(1)

Example
s

of
SWIFTSolutions

&

Market

Initiatives

Send Payload

RT

Client






TSU (SAG

only
)

SF

Client (pull)





Funds,
E&I
, Proxy Voting,
AI

Receive
Payload

RT

Server






TSU centr
al (SAG)

SF

Client (pull)

or
Server (push)





Funds, E&I, Proxy Voting,
AI

Send Request

SF

Client






Cash Reporting

Info
User,

TARGET2

Respond
Request

RT

Server


X



Cash Reporting

Info
Provider

(1)


X


not available.




available

f
or all formats. SA
A 6.2 supports any
XML
payload.
P
revious SAA versions support any MT and MX formats.

The Financial EAI
should

support all InterAct modes to cover the needs of all SWIFTSolutions and
market
initiatives.
The Messaging Operations guide (
see

UHB
)
should

be strictly
adhered to
.


The
SWIFTReady Financial EAI
should su
pport

all

InterAct
modes
through
SAA (AFT and MQSA)
and optionally through SAG (RAHA or MQHA)

3
.3
SWIFTNet FileAct

SWIFTNet FileAct secures the transfe
r of data files usin
g RT or SF

protocols. SWIFTNet FileAct is
particularly suitable for bulk payments, securities corporate actions, r
eference data and reporting, but
is
also

used

for central
-
bank
and

intra
-
institution reporting, and
for
c
heck images.

SWIFTNet F
ileAct support
s up to 250 Mb

in RT (
25

Mb

in SF mode) of structured and unstructured

data. Today,
SWIFT
Central

Services

validate and store the he
ader, but not the file content.

SWIFTNet FileAct
is supported over SAG with

dedicated host adapter
(FTA or FTI) or generic MQHA
(for up to 100 Mbytes
payload
)

or RAHA
adapters.



greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
10

SWIFTNet FileAct Adapters

Function

Mode

Server /
Client

SAG

FTA

SAG
FTI

SAG

RAHA
-
MQHA

Examples of
SWIFTSolutions

&
Market
Initiatives

Send File

RT

Client







Bulk Payment
, Data distr. user

SF

Client







TSU, Bulk Payment,
SCORE

Receive File

RT

Server







Bulk Payment, Data distr. user

SF

Client (pull)





TSU, Bulk Payment,
SCORE

SF

Server
(push)







TSU, Bulk Payment,
SCORE

Fetch File

RT

Client

X






TARGET
2 (ancillary systems)

Serve File
(Download
server)

RT

Server







Data Distribution service
provider

As of 2008,
FTA support is
mandatory

for
the
EAI label, while MQHA or RAHA support for FileAct
becomes

optional
.


The EAI should implement the
Messaging Operation
s Guide
. In particular, the FileAct
Request

Type

should

follow a predefined structure,
and the FileAct
FileInfo

header field
should

spe
cify if the file is
compressed
or not
.

The EAI should be able to use standards compres
sion algorithms as specified in
the
FileInfo

header.


With SWIFTNet R6.1, the EAI should ha
n
dle the FileAct business header for routing purpose. This
business header

is used for instance to capture business

information (number of payment transaction,

curr
ency, total amounts) con
tained in the Bulk P
aymen
t file and is required for SEPA.

Practically, this means that every file that contains a bulk of
pacs

or
pain

messages should calculate the
number of payment transactions in the file and update the
TotalNum
berOfTransactions

field in the File
HeaderInfo

structure.

The labeled EAI should

support the SWIFTNet Bulk Payment R2.0 rule book as described in the
related
Service
Description

available in the UHB.

For Securities, t
he EAI should be (optionally) able to support the Giovannini rule book describing
(amongst others) file format to exchange payload with Euroclear CCI.



SWIFTReady Financial EAI Label criteria


Support F
ileAct RT and SF

through SAG FTA or
FTI

Support Messaging Operations Guide (structured FileAct Header and compression
algorithms)

Support

SWIFTNet R6.1 and Bulk Payments 2.0 rulebook for SEPA
.

Support of RAHA or MQHA becomes optional

Support of Giovannin
i rule book is optional

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
11

4
Standards

SWIFT develops

business standards to support trans
actions in
every financial
market
.

SWIFT
MT

messages
have

progressively been
complemented by XML
-
based

messages, which enable the
transfer of r
icher data for
complex transactions.


T
he Financial EAI
should

support all
existing MT

and MX

for all existing categories
, as described in
SWIFT
User Handbook (
UHB
)
. Message support implies the capacity to generate business payload

using technical adapters

to applications
, file systems

and databases
(
such as
ODBC/JDBC, JMS,
MQ
)
,
to
wrap them
w
ith
in

SWIFTNet
FIN, InterAct or FileAct
envelopes

and validate them against the
SWIFTS
tandards and rules books.

4
.1
MT

The 240+
FIN messages

c
onvey business payload named

Message Type (
MT
). Each MT is defined
by a three
-
digit number and holds a specific business meaning.
MT are categorised as follows:

Category

Category Name

Number of Messages

1

Customer Payments & Cheque
s

18

2

Financial Institution Transfers

17

3

Treasury Markets


c潲敩g渠nxc桡n来Ⱐ䵯湥y
䵡rk整e…⁄敲 v慴iv敳
cu䵍F

27

4

Collections & Cash Letters

18

5

Securities

66

6

Treasury Markets


Pr散io畳⁍ 瑡ls…⁓y湤ic慴i潮s

20

7

Documentary Credits & Guar
antees

29

8

Travellers Cheques

18

9

Cash Management & Customer Status

29

M
T Messages are gathered into Business Transactions (Trading, Settlement, FX). For instance, a
Trading Transaction includes Order to Buy (MT502), Trade Confirmation (MT515, MT518)
, or
Statement messages (MT576).

A Financial EAI should be able to parse any of the240+ MT messages coming from a SWIFT
interface. It should be able to validate the 150 most commonly used

MT

as listed in
Annex A

against SWIFT s
yntax
and semantic

rules.

4
.2 ISO15022

ISO 15022 de
-
couples business elements from physical representation, and ensure that business
items are always represented the same way, irrespective of the message contents. It provides the
tools to define MT standar
ds used in the Securities industry. These tools consist of a set of syntax and
message design rules, a dictionary of Data Fields and a Catalogue of MT Messages using these Data
Fields and rules.

Business Elements (such as Net Cash Amount, Cut
-
off Time, an
d Beneficiary) belongs to Business
Classes (such as Amount, Party, Date/Time). Business elements are reused across MT messages,
bearing the same syntax, tag and business rules.

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
12

The Financial EAI should support the ISO 15022 data dictionary. In particular
, each Data Field
element and related qualifiers should be centrally managed, so that each data field update percolate
up to all MT messages that use this data field.

This logical link can be implemented in various forms as long as the user can find the c
orresponding
business data in related messages. This implementation leads to data mapping in the following two
logical steps:



Identify the business meaning of every field in the incoming message



Generate automatically the corresponding business message in
cluding these business elements.


A Financial EAI should be able to map field values into a canonical, syntax neutral
representation using a central dictionary me
thodology.
The same applies for SWIFT incoming
messages parsing and storage.

4
.
3

MX

Leveraging

the emergence of XML as de fact
o

standards for inter
-
systems communication, SWIFT
uses the U
NIFI (ISO20022) methodology to
design standards, based on business
processing
modelling
.

The UNIFI methodology uses a central
data
dictionary containing reusable b
usiness
elements to build XML standards,

named
MX
, that

are used in business transactions

and provide
interoperability across financial services
.

At the end, the whole financial community will move to MX, but adoption will vary by
business area,
depending on the drivers.

SWIFT intends to provide translation rules to support interoperability in
business areas where coexistence of MT and MX is necessary.

First translation rules for Funds and
Payment have been published on
www.swift.com/standards

.

The
250+

available MX

messages

are
structured according to
market segment
s

Market

Segment

Number of
Messages

Payments

Payment initiation

5

Payments Clearing and Settlement

7

Exceptions and

Investigations

14

Invoice Financing Requests

3

Cash Management

Cash Reporting

31

Trade

Trade Service Utility

50

Securities

Trade

18

Settlement

11

Data
Reference

3

Management

7

Cash F
o
recast

6

Pre
-
trade

44


Investments

23

Tr
ansaction Re
gulatory Reporting

4

Proxy Voting

8

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
13

Market

Segment

Number of
Messages

FXMM and
Derivatives

Non
-
deliverable Forwards

7

Currency Options

4

Generic

4


MX
supports

XML
features, such as the
facets
on simple data type
(pattern, min and max length,
numerical limits, enumeration,
max digi
t and decimal numbers
).
MX also supports complex data types

to gather common characteristic
s that are inherited by XML schemas and XML instances.

Schema validation

involves
syntax
checking
against

well
-
formed XML rules (single
-
rooted

paired
elements, openi
ng and
closing

tag
s
). In
addition

the
X
ML instance must be
validated

against

its
corresponding schema (XSD), including
allowed character set, format,
cardinality, enumeration,
and
mandatory
/optional

presence.

XSD are available in deployment packages on swi
ft.com/support.

Extended
validation

ensures that the message is validated against
the
MX rule Book. It involves cross
-
element (if field A is present then field B must take value X or Y), intra
-
element (the fractional part of
an amount is checked against th
e currency), calculations (check digit of IBAN code) and external table
look
-
up (BIC, Country or Currency Code).

The EAI should be able to parse any MX message and validate it against the XML schema
.
The

EAI should be able to support Extended Validation fo
r the generic fields present in most MX. A
complete list of generic fields that should be validated is provided in section
6
.
2.

4
.4
ISO20022


ISO 20022 provides the financial industry with a common platform for the development of messages in
a standardized

XML syntax, using:



a
modelling

methodology
, based on UML to capture

financial business
models
, business
transactions and associated message flows
into syntax
-
independent data dictionary



a set of XML design rules to convert the messages described in UML i
nto XML schemas


SWIFT applies the ISO 20022 definitions to structure SWIFT
Standards
XML
(MX)

message
types. Any
MX artefact (XML element, simple or complex type,

attribute) has a corresponding business artefact
definition

(message component, element, dat
a type)
. MX and business artefacts are both represented
in UML.

The IS
O
20022
Financial
Dictionary contain
s

reusable
items, which can be categorised into Business
concepts (association, component, rule, actor and role), Data Types and Message Concepts
(mess
age element and rule).
Non
-
reusable artefact
s

(Business

Processes, Information flows, MX
messages,
and technical

message elements) are found in the SWIFTStandards Reference Guide
.

The ISO2022 Data Dictionary
can be

available in
electronic downloadable

form
at.

A

Financial EAI should support the ISO 20022 data dictionary,
i.e.

all reusable
business
elements and components
, as basis for parsing, val
idating and storing MX messages and
associated rules.

4
.5
FpML


The Financial
products

Mark
-
up

Language (FpML) is

an XML messa
g
e standards developed for the
OTC Derivatives industry.
SWIFT

create
d

an FpML Closed User
Group

(CUG) linking buy
-
side wi
t
h
greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
14

asset
-
servicing institutions, to transport FpML messages related to trade
notification

process for
interest rate and c
redit derivatives.

FpML 1.0 enables the transport of contract notification messages between buy
-
side and custodians.

FpML2.0 will be delivered in Mach2008 and include cancellation of post
-
trade events and
confirmation
messages.

SWIFT central services wi
ll validate FpML 2.0 messages against

-

Syntactical rules (FpML schema validation)

-

ISO references (Country, Currency codes and BIC)

-

Semantic rules (cross field validation rules available for products Type = IRS, CDS, CDX or CXT
)
.

The
contract FpML
2.0

mess
ages

(Created, Novated, Increased, Terminated and Cancelled) should
be supported
.


The Financial EAI should be able to validate FpML

2.0

syntax against its FpML schema.

FpML
semantic validation
will be recognised as an optional feature of the EAI.


4
.6 SWI
FTSolution
s


As of
2008
, the EAI can optionally support the
SWIFTSo
lutions
messaging requirements.

A SWIFTSolution is considered to be supported by an EAI when
this one

is able to:



Extract data from business application
s and transform it into the MX, MT and FpML formatted
messages mandated by the SWIFTSolution



Validate the message payload

against the
XSD, and
SWIFTSolution rule
s

book, as described in
the UHB SWIFTSolution Service Description



Integrate with
SWIFTAlliance

Access

and/or Gateway



Ensure
Technical reconciliation

over SWIFTNet and counterparty responses

(acknowledgement,
delivery notification)


The EAI does not need to implement the business logic requested by a SWIFTSolution.

This business logic is typically ma
naged by
some

business application and includes:



Data creation through manual data entry or data consolidation from different sources



Human manipulation on generated data (enrichment, validation, authorisation, repair)



Business transaction management, ensu
ring

data reconciliation at business level, and proper
business answer on incoming requests.

The SWIFTReady Solution labels rewards a business application for the implementation of the
required business logic which, typically, will not be supported by an E
AI.

SWIFTReady Financial EAI Label criteria


Support of all MT, and MX messages (parsing, mapping, validation, serialization)

Support of ISO15022 and ISO2022 dictionaries.

Support of SRG 2007 and MFVR 2007

Support of SWIFTSolutions and FpML messaging re
quirements is optional

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
15

5
.
SWIFT Connectivity

The Financial EAI
should

integrate
at least

with
SWIFTAlliance Access (SAA) to support the different
SWIF
TSolutions
and
M
arket I
nitiatives
.

The last columns of the following table displays the list of adapters that
are able to
support
a given

SWIFTSolution
, either completely (marked with
√), or partially

(
in which case, the
limitation is provided).

EAI
partners

should select SWIFT adapter based
on the

SWIFTSolutions that they want to support.


SWIFT
Solution
s

&
Market Initiative
s

Standard

Messaging

Mode

Model

SAA


AFT
MQSA

SAG

RAHA
MQHA

SAG

FTA

FTI

C
ash
Reporting

MX

IA

SF

Client or
Server






Funds

MX

IA

SF

Client or
Server






Exceptions &
Investigations

MX

IA

SF

Client or
Server






TSU

XML

FA

RT


SF

Client or
Server






IA

RT &
SF

Client or
Server






Data Distribution
Corp
orate Actions
Reference Data

MT,
Prop
rietary

FIN, F
A

RT

Client

( DD User)

MT



FA

Server (DD
Provider)




FA

Accord

MT, XML

FIN, IA, BR

RT

Client

MT




TARGET2

MT, XML,
MX (Cash)

FIN, IA, FA

RT


SF

Client or
Server

MT, MX




Bulk Payment
SEPA

MX, MT,
Proprietary

FA

RT


SF

Client or
Server






CLS Third Party

MT

XML

FIN

IA


RT

Client or
Server

MT




Affirmation
s

(Accord)

XML

IA

RT

Browse





Proxy Voting

MX

IA

SF

Client or
Server






Giovannini CSD
Access


FIN, IA,FA

RT

SF

Client or
Server

MT, MX




FpML

FpML

IA

SF

Client or
Server

FpM
L




SCORE
/ MA
-
CUG

MT, XML

FIN, FA

RT
SF

Client or
Server

MT



FA

Transaction
Reporting

MX

FA

SF

Client or
Server






greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
16


5
.1
SWIFTAlliance Access (SAA) integration

SAA

R6.0

provides the following adapters:

1.

WebSphere MQSeries host Adapter (MQSA)

allow
s
the exchange of

any

MT and MX
messages across a very large range of operating systems and platforms.

2.

Automated File Transfer (AFT)
. MT and MX are bulked together in files that are transferred in SAA
Input directory. Messages coming from SWIFTNet are rea
d from SAA Output Directory.

3.

SWIFTAlliance Access Developer Toolkit (ADK)

provides a set of API to tightly integrate with
SAA workflow engine
.

The Financial EAI should at least support the first two.

As of SAA R6.2

(March 2008)
, these adapters
will
suppor
t any XML
messages with UTF
-
8 encoding.

SAA R6.2 also introduces a new MQ adapter, based SAA Application Interface instead of ADK. The
support for this new adapter is not mandated for 2008, but its optional support will be recognised.

SAA exchanges informa
tion with EAI through Protocol Data Units (
PDU
). A PDU wraps business
information within an envelope that carries sender/receiver addresses, format and security items.

Different PDU formats are made available, as described in the S
AA Sy
stem Management Guide, part
D, A
nnex G.5. As of SAA 6.0, PDU are available in XML format for both MT and MX messages.

The Financial EAI should be able to support at least this new XML format, named
XML Format V2
,
and that include

the following

PDU dat
a types:

-

Message
, that can be MX or MT messages exchanged between EAI and SAA

-

MessageStatus
, providing the result of SAA validation processing, including error code.

-

TransmissionReport
: containing the Transmission Notification and original message

-

Deliver
yReport
, containing the Delivery Notification reconciled with original message

-

DeliveryNotification
, without original message but with some reconciliation information

The following
integration and reconciliation mechanisms should be provided:

MQSA support


MQSA
supports the exchange of
any MT or MX
PDU
,
and
the reception of

Information Notification

(local
SAA syntax

and signature validation result), Tr
ansmission
N
otification

(
ACK/NAK
)
,
and
D
elivery

N
otification
.


The EAI should use
MQSeries Local Reports
f
eature to
(1)

reconcile messages

in EAI repositories

using the Correlation Identifier and
(2)
convey notifications to back
-
office applications.


Exception behaviours (
NAK and non
-
delivery notifications
)

should
raise an alarm and trigger
message routing to

the

EAI repair
station
.


The EAI should support MQSA for any MT and XML messages (MX or FpML) required by
SWIFTSolutions
or

Market Inititiatives
, and
available

on
www.swwift.som/support

>
Download
C
entre as s
tandards packages to be deployed over SAA for testing purpose

AFT support


AFT supports the automated exchange of
a mix of MX and MT

batched into a file and
provided in
a

local or remote
file system
.

AFT allows to:

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
17

-

B
atch MT /MX messages in a AFT
-
formatted
file, and transfer it (
using
FTP or other) to AFT
Input Directory, after
HMAC
-
SHA256 signature

-

Read files form AFT Output
Directory;

un
-
batch th
e files into MT and MX messages,
Message
Status (result of local SAA validation),
Transmission Notifications

(re
sult of
SWIFT Central
Services

validation)

and Delivery Notifications.

-

Reconcile
Transmission Notifications (
ACK

and NAK
)

with sent messages

-

Reconcile Delivery Notifications (positive or negative) coming from counterparty

-

Handle

exceptions (NAK, file forma
t errors, signature errors, duplicate handling) by reading
into AFT Error and Report Directory and
route to
Exception

Handler

Not
e

that
AFT has limited capabilities in terms of
local reconciliation. Files that are rejected (wrong
file format or signature)
can be retrieved by the EAI through error reports, but once the file has
been un
-
bulked, the invalid messages are route to SAA repair queue, and can no longer be
handled back by the EAI.

In addition, AFT
does not manage sequence control, and is not approp
riate for time
-
critica
l or
high
-
volume applications.

AFT

should be supported by
EAI as an
alternative to MQSA.

ADK Support


The ADK is a collection of software and documentation
that allows tightly
integration

with SAA
workflow engine (routing points, jou
rnalizing, and interventions history).


The ADK provides
API
libraries that can call a subset of the services provided by

the
SWIFTAlliance servers both for MT and MX messages.


ADK support is not required

for the SWIFTReady EAI label
, but the support of
ADK will be
recognised as an optional feature, and published as such.


SWIFTReady Financial EAI Label criteria

Support both AFT and MQSA for all MT and MX messages.

Support XML Format V2

Support all MX messages available on download centre (www.swift.co
m/support)

Conformance Testing should be performed on
SAA
R6.0
and optionally on
R6.2
(March08)

5
.2
SWIFTAlliance Gateway (SAG) integration

SAG R6.
1

provides the following adapters:

1.

Remote API Host Adapter (RAHA)


It
provides a set of APIs available on
3 platforms (AIX, Sun and Windows). RAHA support tight
integration of any FileAct and InterAct flows in any modes (Store&Forward or real
-
time, push or
pull modes).

2.

WebSphere MQSeries Host Adapter (MQHA)


It
provides the same level of integration for FileAc
t and InterAct on a vast range of platforms.
MQHA is not recommended for FileAct, as MQ files are limited to 100 MB while FileAct can
transfer up to 250 MB in real
-
time mode.

3.

Web Service
SOAP
Host Adapter (WSHA)


It
enables a

Web services
application that
connects

to SAG
to exchange SOAP messages with
another application

over
SWIFTNet
.
The SOAP format i
s translated by WSHA into InterA
ct RT
message.
FileAct can also be used when both sender and receivers are using WSHA.

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
18


4.

File transfer Agent / Integrated (FTA
/FTI)
.

FTA and FTI both support FileAct RT and
SF
. Files are transferred to SAG directories. FTA
automates file transmission, while FTI waits for a user of application command to be issued.
For
the current releases, nor FTA neither FTI

can

guarantee data
confidentiality in DMZ
.


RAHA/MQHA Support


ACK and NAK

received from SAG need to be reconciled and make sure that in case of problem, the
appropriate action is taken, and exceptions are properly handled.


RA/MQ is not mandated for the EAI label 2008 for F
ileAct and InterAct.
As of SWIFTNet R7.0, any
application that interfaces directly with SAG using RA or MQ, will be subject to qualification as SWIFT
Interface provider.

WSHA Support


WSHA is the new SOAP adapter, available with SWIFTAlliance Gateway R6.
1

for SWIFTNet InterAct.

WSHA will not be mandated as part of the EAI Label. Support will however be recognised as an
optional feature.

FTA/FTI

support



SAG 6.1 FTA or FTI needs to be supported for the2008 label.
The EAI should correctly handle

structured
FileAct header in emission and rec
eption. This involves the enhancement of
parameter files
Sw:HeaderInfo

fields
to includ
e

the number of transactions in each file and specify the result in the
TotalNumberOfTransactions

data element of the
File
Header

Info.

For FTA
/FTI
, the Companion parameter file (File Transfer User Guide R6.1 section 6.2) should be used to
convey detailed information that is used by FTA to complete header information.

Some additional functions
of SAG 6.1
may be supported as optional feat
ures:

-

File T
-
Copy and Y
-
Copy services

-

SWIFTNet Advanced Delivery Control for SF protocol (input
channel, Sequence numbers,
FIFO)

5.3 Back
-
office integration

The
EAI

should be deployable
on various platforms including .NET and any J2EE compliant applicati
on
servers
-

the primary platforms used to host Web Services
.

It should run at least on UNIX (HP, Solaris, Linux) and Windows platforms.

The
EAI

should optionally provide adapters to various Messaging Queuing, Databases, and Communication
systems, Busin
ess applications and Utilities to extract and map data into MT and MX messages.

Non
-
exhaustive lists of optional adapters that may be considered for SWIFTReady validation:

-

Message Queuing
: BEA MessageQ, IBM WS MQSeries, Microsoft MSMQ, Oracle AQ, Tibco Ren
dez
-
Vous

-

Database
: Oracle, DB2, Microsoft SQL Server, and any ODBC/JDBC compliant RDBMS

-

Communication
: COM, CORBA, FTP(S), HTTP(s), SOAP, Socket, EDI VAN

-

Business Application:

Siebel, SAP, PeopleSoft, Oracle and other CRM / ERP / Treasury applications.

-

Uti
lities
: Archive (ZIP/TAR), Batch, File *, GZIP/ZLIB, LDAP, MIME, SNMP, XML* )





greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
19


SWIFTReady
Financial EAI Label criteria


Support FTA or FTI to connect to SAG

1. The support of RAHA/MQHA for all InterAct and FileAct is no longer mandated for
FileAct sup
port. The support of these adapters is subject to SWIFT Interface
qualification as of SAG 7.0

2. Conformance Testi
ng should be performed with SAG

6.1

3. Advances Delivery Control and T/Y
-
Copy support are optiona
l



greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
20

6


Message Validation

6
.1
MT

Message Va
lidation

SWIFTNet FIN C
entral
S
ervices

validate
every FIN message

against syntactic

and semantic rules.
Messages that do not pass validation are rejected by the system
, incurring substantial cost for SWIFT
Users
.
To avoid this,
a
Financial EAI
should provi
de

the same level of validation as
SWIFT
Central

Services

does.

FIN messages are composed of different block
s

(headers, body,
and trailer
).
Message

body
should

be
a valid
MT
.

A well
-
formed
MT is composed of [sequence
s

of]
fields
. A
valid field is

made of
f
ield
t
ag
s

(2 digits 0
1

to 99)
,

optional

letter (A..Z)

and
C
omponent ([string of] characters)

with optional
Q
ualifier
.

Fields are
characterised by their presence in a message (optional, mandatory), their cardinality (allowed number
o
f occurrence), and
allowed

values
.

Several MT rule layers have been added during
the years.
Most

are checked by
SWIFT
Central

Services
.


MT Rule Name

User
Compliance

SAA Validated

SWIFTNet
Validated

Gole EAI
Support

MT Message Format
Validation Rules

Mand
atory

Partial (character
set and Syntax)

Yes (full
validation)

Mandatory

MT Usage Rules

Mandatory

No

No

Mandatory

STP Guidelines

Optional

No

No

Optional

Market Practices (SMPG)

Optional

No

No

Optional


Message Format Validation Rules (MFVR)

The
Netwo
rk Validation rules
are defined in the Message Format
Validation

Rules

(MFVR) in SWIFT
UHB
.

MFVR is updated on regular basis,
following the SWIFTStandards Release cycle
. The Financial
EAI
should

follow the MFVR evolution.




Valida
tion


Purpose

Code

Examples

Character
Set

Valid

character set
;
message
,
field and sequence

length

Mxx

SWIFT defined
3 character set (X, Y, Z)
depending on
usage

Synta
x

Field and component format
;
mandatory fields and sequence

Txx

T13

:

field tag is not

expected at this location

T27:


BIC incorrectly formatted or invalid.

Code

Word

Valid code word usage

Kxx
and
T
0
x

Code word:
‘D’

for Debit, ‘C’ for Credit

T05
-

Code word error in
Field 68B, subfield 4, in
MT

609

Semantic

Cross
-
field validation
(condit
ional)

Over 300 rules are defined
across the 200 MT

Cxx
to
Exx

C02:

The currency code
should

be the same for
all
currency
occurrences in the entire

message.

C05
-

BIC
should

NOT be a BEI, BEID or TRCO

C18
-
If fields 32
B and 71B are present, field 33
should

be present.

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
21

Valida
tion


Purpose

Code

Examples

MUG

Message User Group

(24 rules)

Gxx

G07 CLS : in an MT300 eligible for the FIN
-
Copy
service CLS or CLT, any

Field

53 present in sequence B
should

be used
with the letter option “A”.

VAS

Value
-
Added Service

related (5
rules)

B
xx

B01:

PAC T
railer used for non
-
FIN Copy service
message.


MT Usage Rules

Usage Rules

are not validated on the network,

and do not generate

error code
. Usage Rules are
nevertheless mandatory for the correct usage of
MT

field.
The Financial EAI should support Usage
Ru
les.

Some examples in MT103

-

Field 33B Currency: used when the currency and amount are different from those specified in
field 32B.

-

Field 36 Exchange Rate:
should

be present when a currency conversion or an exchange has
been performed on the Sender's side.

-

Field 77T can only be used if both Sender and Receiver of the message have subscribed to
the Extended Remittance Information MUG. If the field is used, the Sender
should

set the
validation flag to REMIT in field 119 of the user header of the message. If f
ield 77T is not
present, the code of the validation flag
should

not be REMIT.

STP

Guidelines

STP
Guidelines are not validated on the network and are not mandatory for the correct usage of the
message. They con
cern
best

practices. Guidelines

affect more tha
n one field in the message, or more
than one SWIFT message. It identifies specific issues, and provides clarification and examples, with
the aim to improve straight
-
through processing.


This includes generic principles, such as avoiding the use of full na
me and address for a financial
institution
.

More and more, banks are charging for non
-
STP compliance, and EAI should be able to
detect these non
-
compliance.

Market Practices

Market
Practices are
defined

by Industry groups to globally harmonise market pract
ices
to enhance

STP at an industry level. The Securities Market Practices (
www.smpg.info
) is a g
lobal securities
industry group

setup in 1998. SMPG

objective includes the harmonisation of non
-
regulated
geographical differences as well as the consistent imp
lementation of ISO
150022

messaging standards
by securities industry participants for processing within and across all markets.

SMPG
are currently
active in more than 30 countries and are made up of the different players in the securities markets
(custodian
s, fund managers, broker
-
dealers, IMIs etc). Discussions focus on automation and end
-
to
-
end processing throughout the securities life cycle.

Market practices include country
-
specific settlement rules for
MT53x and 54x messages
.They cope
with

common specia
lisations such as making certain qualifiers Mandatory, for example /PSET/, and
BICs become mandatory.

Market practices are currently being invest
igated for the Payment market.
However, i
n
2008
, P
MP
G will have
no

impact on message validation, and will not b
e part of the
Financial EAI validation.

M
arket practices can be seen as an instance of a FIN message where some optional fields / keyword
become m
andatory for a specific country, or a specific market.

More recently, the
Payments Market Practice Group (
PMPG
) has been introduced to provide market
practice recommendation for implementation and use of payment messages, as related to financial
greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
22

instrument transactions inclusive of instruction, confirmation and status messages between investment
managers, custodia
ns and subcustodians.
PMPG is not mandated yet for 2008.



SWIFTReady
Financial EAI Label criteria


Support of FIN, FMVR 2007 and Usage rules

Demonstrate support of Generic Securities Market Practices and STP Guidelines.

Show capacity to support additional

Market Practices with marginal cost and
minimum implementation effort.

6
.2
MX Message
Validation

MX messages
should be

validated
against
relevant XML schema and against
Extended Validation
Rules that are provided in
the
MX rule

book
s
(
SWIFTSolutions Serv
ice Description
).

Extended

V
alidation

R
ules

should be
applied on the following generic MX fields:



XML elements of type BIC (Datatype: BICIdentifier) should be checked against existence in
the BIC directory
(ISO 9362)



XML elements of type BEI

(Datatype: BEI
Identifier) should be checked against existence in
the BEI list on SWIFTNet



XML elements containing an amount
AND

a currency (Data Type: ActiveCurrencyAndAmount
and ActiveOrHistoricCurrencyAndAmount) should be checked for existence against Currency
Code
I
SO 4217
, and against the number of digits of the amount as specified by ISO
4217

for
that specific currency



Country codes (Data Type: CountryCode)should be checked for existence against
ISO 3166




IBAN identifiers (Data Type: IBANIdentifier) should be va
lidated against IBAN
structure

as
provided by
ISO 13616

(Country Code, check digits and a basic bank account number)



XML elements of type
BICorBEI

(Data Type: AnyBICIdentifier)

should be checked against
existence in the BIC list on SWIFTNet



XML elements o
f type
ActiveCurrency

(Data Type: ActiveCurrencyCode) should be checked
against existence in the currency list on SWIFTNet



XML elements of type
ActiveOrHistoricCurrency

(Data Type: ActiveOrHistoricCurrencyCode)
should be checked against existence in the c
urrency list on SWIFTNet

Other rules may apply for particular
SWIFTSolutions
. The support of these additional rules is optional
for the
EAI label
.

The XSD for the following solutions should be supported by default in the EAI:

-

Cash Management Push

and
Cash

Reporting R3.0

-

F
p
ML R1.0

-

Funds R4.0

-

Exceptions and Investigations R1.1

-

Proxy Voting R1.0

-

SCORE 2.0

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
23

These are available on
www.swift.com/support

> Download Centre > SWIFTAlliance SWIFTStandards
Packages.



SWIF
TReady
Financial EAI Label criteria


Validate all MX messages against XML Schema (XSD)

Extended Validation on generic MX fields


SWIFTSolutions support will be recognised as optional features of an EAI. To support a
SWIFTSolution, the Financial EAI should

support the complete rule book provided with
every SWIFTSolution Service Description; develop an adapter to at least one business
application, and ensure E2E testing with one customer.

6
.3 Giovannini File Transfer Rule book

Giovannini rulebook identifies

generic header, content and operatio
nal requirements to improve
interoperability

of exchanges between financial institutions.
It includes specific rules concerning
packaging of content for file transfer,
on top of

technical an
d security standards. The rul
ebook provides
a generic framework that is used as basis by market infrastructure to push forward file exchange
automation. Euroclear CCI intends to refine Giovannini rulebook for March 2008.


Support of Giovannini rulebook for CCI will not be mandated, bu
t recognised as an optional
feature of the EAI.

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
24

7
.
Reference Data

7
.
1
BIC

I
ntegration

The BIC D
irectory is a
database

containing the exhaustive list of institutions connected on the SWIFT
network.

The Financial EAI should provide access to these director
ies
both for message
validation and as look
-
up function in the message creation and message repair station
s
.

The
BIC D
irectory

is downloadable fro
m
www.swift.com

in full or delta versions. It
should
either
be
copied

i
nto
the
EAI repository system, or
stored in back
-
office
for access

by the

EAI through
defined

interface.

In 2008,
SWIFT

intends to

provide the BIC Directory monthly updates through FileAct. This will allow
the EAI to automate the BIC Directory update.

7
.2
BIC
Pl
us
IBAN


SWIFT introduced the
BICPlusIBAN Directory
, allowing
financial institutions to
seamlessly switch
between

beneficiaries BIC
and corresponding Bank National Codes. It also
allow to derive the

BIC
from the
Internati
onal Bank Account Number (IBAN)
in outgoing SEPA payments

over 31 countries
,

or

validate that both

IBA and IBAN

belong to the same institution.

Furthermore, the BICPlusIBAN provide look
-
up facilities for bank/branch
/clearing

codes

against the
BIC benefici
ary BIC
. It also contains banks participation in RTGS systems and many other bank
details.


The directory can
be downloaded from
www.swift.com

on the
BIC Downloads page
.


BICPlusIBAN

supersedes the BIC+ Directory that is being removed from the market.

The Financial EAI should be able to validate the
BICPlusI
BAN
against specific MT and MX
messages,
which

are:




MT102 (STP or not) field tags 52A and 57A (plus 52C and 57C for MT102_not_STP)



MT103 (STP or not) field tags 52A, 56A, 57A (plus 52D, 56D,

56
C,

57
Cand 57
D for
MT103_not_STP)



Pacs MX messages

In MT messag
e, the IBAN of the beneficiary customer is contained in field 59A (preferably) or 59.

IBAN code should be validated
for
pacs

messages used in SEPA
. In particular:

a) the IBAN checksum should be checked with Modulo 97 formula, ISO standard 13616,

b) the co
untry specific IBAN format, should be checked against the IBAN registry format
(downloadable from
http://www.swift.com/index.cfm?item_id=61332
),

c) the national bank identifier

in payment messa
ge
s

should be checked

against the IBAN

d) the BIC issued

in payment message

should be

checked for existence
,

e) the IBAN and the BIC
should be checked as belonging t
o the same institution.

For c), d)

and e) one needs SWIFT's BICPlusIBAN Directory
availab
le on swift.com.

d) can also be
checked against the SWIFT BIC Directory
.


greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
25

As of 2008, Financial EAI should use the IBAN
-
BIC directory to validate the IBAN
-
BIC
combinations
, translate BIC into national
bank/
clearing codes,

and t
o derive the BIC from the
IB
AN

In addition, the EAI shall optionally repair
payment
messages for which the i
ssued BIC and
IBAN do not match, or derive BIC from IBAN when the BIC is missing.

7.3

SEPA Routing Directory


With the
SEPA Routing Directory
, ba
nks sending SEPA payments can verify whether the operational
BICs of their correspondent are SEPA
-
adherent

and operationally ready for SEPA, and which channel

(SEPA
-
ready Automated Clearing Houses)

they can
use for
payments

routing
. In other words, the
SE
PA Routing Directory provides the operational information necessary to exchange SEPA payments
with the institutions listed in the
EPC Register of Participants
.

The
SEPA Routing
directory
specifications and samples
can be downloaded from www.swift.com on
t
he
BIC Downloads page

or on SWIFTCommunity (
https://www.swiftcommunity.net/
)
,

Registered
Vendors

community
.


The
SEPA Routing Directory

contains:



The
BICs and names

of the financial institutions that have signed the SEPA Credit Transfer
a
dherence agreement with the EPC (and later on the Direct Deb
it agreement).



The
operational BICs

of these institutions
which

are able to process the SEPA payments.



The
channels
(SEPA
-
ready
ACH

or other Clearing and Settlement
Mechanisms
-
CSM
)
through which the financial institutions can recei
ve the SEPA payments, and the preference
for using these channels.



At a later stage it will contain the SEPA Direct Debit Scheme information as well.

In 2008, The EAI should
be able to
use this

SEPA

Routing

Directory to

validate

pacs

messages
against
the
S
cheme to be used for a
given
correspondent BIC

before
sending

a SEPA credit transfer
payment instruction.


The
Financial
EAI
should optionally i
mplement the followi
ng logic for SEPA related
pacs

messages to
be sent to SWIFT:



Split the
target correspondent

BIC

into a BIC
Code (8 characters) and

a Branch Code (
3
characters
).
If the branch code is empty, substitute it with XXX.



Search the SEPA
Directory

with

the BIC code, the
branch C
ode,

the Service L
evel (for example,
SEPA),

and the S
che
me I
nstrument (for e
xample, SCT for pacs.
0
08 message and
SDD

for
pacs.
0
03 messages)



If no record is found for a specific branch code, then repeat the search with XXX in the branch

code.



If at least one record is found with an operational readiness date older then the current
date

and
with an active validity period, then the BIC is ready to accept payment instructions for the

service
level/scheme instrument and can receive payment instructions through the payment

channel, and
the message is validated.



If no record is found, the

message should be routed to
manual investigation to validate that the
counterpart

bank is ready to accept SEPA payment instructions.

7.4

MX / MT Directories

SWIFT
intends to

provide

directory services to identify who uses MT and who uses MX

in
areas where

coexistence of MT and MX is necessary
.

This
is

not be mandated in 2008.

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
26

7.4
CIVIC Directory

In 2008, SWIFT intends to introduce a CIVI
C

Directory, containing identifiers of funds using BIC
syntax. The initial scope will include retail funds authorized for

distribution in Belgium, France,
Germany, Ireland, Luxembourg, Switzerland, the UK and the US.

Directory
Services Requirements for EAI label


BICPlusIBAN and SEPA Routing validation on all
concerned
pacs

messages

used in SEPA

8.

Message Processing

8
.1
Me
ssage
Creation

The
Financial
EAI should extract business data from
back
-
office applications

and database
s
,

and map
this data
into MX, MT or other
accepted
SWIFT
formats.
A graphical design tool should provide the
field

mapping and
data
transformation rules

from application format (
IDoc
,
CopyBook,
files,
RDBMS

tables) into MX and MT fields.

Standards message libraries can be used for this purpose.
For MX, t
he
XML payload should be generated
using
the
XSD

supplied by SWIFT
.

Message header should be added acco
rding to data transmitted by back
-
office application
s
, possibly
enriched with correspondent profile data maintained in
the
EAI repository.
Message
s

should be
validated prior

to be rou
ted to SWIFT interfaces.

When creating the Message
Request
Control

header,

the EAI should provide a value for the
Product
List

field.
The
Product
List

should contain

the identification of all products

that are

involved in
the generation of the Request. This information is logged within SWIFTNet,
and

is not

forwarded to the
Respond
er. The
Ve
ndorName

within the
ProductList

should be
the Partner

Identifier Code (PIC) of the
Solution Partner

as
provided

by SWIFT.
Details are provided in SWIFTNet
Service Design Guide.


The
Application
Name

is a short identifier of the application package

and is chosen by the Vendor.

The Product Version identifies the version of the application according to the versioning of the

Solution
Partner.

8
.2
Content
-
based Routing

Business messages
should be

routed from back
-
office applications to the
correct

SWIFT

Interface

(SAA or SA
G
)

and reversely.

The rule engine should allow to route message
s

according

to:

-

Message header content:
sender, receiver,
and request

and service type

-

Message payload content.

For instance:


If

payment
amount
is
larger than
T
hresh
old,
then
route

it

to
exception handling
.

Rule Engine
should

also allow
bulking

payload
s

together
,

prior to wrap

it

into

FIN
, InterAct

or FileAct
envelopes.

Additional processing, such as message transformation
,
enrichment,

local
security
management,
and
s
torage,

sh
ould also be available.

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
27

8
.3
Reception from SWIFT

M
essages received from SWIFT can include several MT messages. The Financial EAI should
open up

and parse
the message
into

separate
payload
s

and

individual
business messages (MT/MX)
.
Message
Valida
tion is not

necessary on incoming messages, but

MT messages should be parsed into
b
usiness
o
bjects

and stored

as such in the EAI repository
.
Depending on target application, Data

transformation

and other processing may be required.


8
.4
Reconciliation

SWIF
T

validates

m
essages at different levels

and provide
s

Notifications about validation and
transmission results
. The Financial EAI
should

capture these
Notifications

and e
nsure technical

reconciliation, error handling, repair and retransmission.

Technical a
nd reference data

error
s

should
be handled

at

the

EAI level
, and the message should only
be routed
to back
-
office applications

if business data is
invalid or incomplete,

and cannot be repaired.










Reconciliation should be handled

at three levels

1.

In
terface reconciliation

(Information Notification)
:
SAA validates
MT and MX
messages against

syntax

and
security
signature
.

Message
s

that
fail

validation
are routed to
specific routing point and
Information Notification
s

and
MessageStatus

are

generated
,
tha
t should

be
captured and
processed by
the
EAI

for
exception

handling and repair
prior to resending
.

Batch f
iles provided to SAA through AFT
should

also
be
checked
against file format and
duplication.

Invalid files are sent to SAA

Error Directory, and
an
XML error report is
generated in
the

SAA
Log
Directory
.

The

EAI s
hould be able to read from the

SAA
Error and Log
Directories
,

and

forward
invalid

message
s

and
XML report
s

to the EAI
Exception Handler

for repair
.


SAG is not a Store&Forward
interface

and d
oes not provide
this level of
Notification.

2.

Network reconciliation

(
Transmission Notification
)
: For most services (FIN, InterAct and FileAct
S&F), messages are validated by SWIFT Central services that return ACK or NAK messages.
SAA map
s

these into
Tr
ansmi
ssionNotification
s

and mak
e them available for the EAI

through
MQSA or AFT
. The Financial EAI should read these ACK/NACK and act as appropriate: ACK
should be reconcile
d with
the
original message

using the Notification’s
SenderReference
, and
NA
K shou
ld be
sent to Exception Handler

for repair and possible Transmission r
etrial.

3.

Counterparty reconciliation

(D
elivery Notification
)
:

on reception of a message,
the counterparty
issues an acknowledgment that is transformed by SWIFT Central Services into a

Delivery
Notification

(
DelN
)

and made available to the sender
.
On SAA, Del
N are mapped into
Delive
ryR
eport

or
DeliveryNotificati
on
, depending on Traffic reconciliation set up in SAA.

For InterAct and FileAct
SF

on SAG
,
DelN

should be fetche
d from central queues
.

For
InterAct and
FileAct

RT

on SAG
, the DelN is
replaced by the R
esponse of the interactive
Query/
Response mechanism.
In any case, the
DelN

should be conveyed to back
-
office application
for message reconciliation.

Non
-
delivery notif
ication
should

lead
to transmission

retrial, preferably

initiated by the EAI.

Financial EAI
Back
-
office
Application
SWIFT
Central
Services
SAA
Information
Notification
Transmission
Notification
Delivery
Notification
SAA
Financial EAI
Back
-
office
Application
SWIFT
Central
Services
SAA
Information
Notification
Transmission
Notification
Delivery
Notification
SAA
greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
28

Finally, a

Business reconciliation involving business response

may take

place in back
-
office. For
instance, a Trade Allocation (MT514)
is
responded by a trade Confirmation (MT515
). This business
reconciliation is usually not managed by the EAI,
but by the back
-
office application. However, in some
occasions,
a

BPM
is able to cope

with some level of business reconciliation,
a
s it happens for
Exception
s&
Inves
tigation
s

SWIFTSolution.


Reconciliation notifications should be reconcile with original messages that have been stored in the
EAI repository. The propagation of every reconciliation notification to back
-
office applications should
be provided as a configur
able option.

Additional details

on reconciliation process and notification message formats is provided in SAA
System Man
agement Guide, part D, Annex G5
.

8
.5
Message
Repair
and Exception Handling

EAI should be able to repair messages prior to send them to t
he interface.
Repair

can be mandated to
avoid network rejection, but also, it helps decrease cost for non
-
STP compliance.

Repair can be automated or manual.



Automated Repair
: the validation engine identifies inconsistent or incomplete dat
a

(BIC is missing,

or not aligned with provided bank name and address), and correct the message to ensure STP
compliance. This
is usually

based on data pattern matching systems originated form Artificial
Intelligence paradigm.



Manual Repair
: faulty messages are routed to ma
nual intervention (usually a web browser or
classical GUI). Message should appear with business field tag and provide look
-
up function for
BIC and
other

reference

data
.
It may also be required to change security related parameter and try
to retransmit it

T
he Financial EAI should at least provide
a
Manual Repair station with
reference data
look
-
up
function. Manual intervention should be recorded for audit purpose.

Messages manipulation
should be

restricted with user
with dedicated security profile.
Actions t
aken on
messages will be logged, and messages will be stored before and after manipulation for audit
purpose.

The message editor
should

be format aware. In particular, field name
s

will be expanded, and field
options will be provided
as drop down menu

(ex:
code words, dates, BIC look
-
up).

8
.6 Duplicate and Retry management

I
n case of transmission failure,
the EAI will retry transmission a configurable number of times. This
hold
s

for InterAct an
d

FileAct processing. Retransmission attempts will be
notified

as

PDE

indication
.

8
.
7
Event Logging

Financial EAI should log events

related to message lifecycle (c
reation,
validation, repair, authorization,
sending
, ACK/NAK, de
livered, reconciled) for audit purpose.
Important events should be co
nsolidated
into BAM.

8
.
8
Message
Archiving

Message that pass
es

through the EAI should be safe
-
stored

together with all intervention and
reconciliation that occurred on the message (creation, mapping, validation, authorisation, reconciliation
against interf
ace, network and counterparty).

To ensure an efficient follow
-
up of the trans
action, transformation

and routing at the EAI level, the
greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
29

ability to access copies of the transported and converted messages is requested.

As the originator may be located in a di
fferent time zone, a copy of the message before and after
transformation has to b
e accessible for error tracking
. Archiving does not need to cover a long period
of time but may be able to ensure 24/7 operations.

Archiving can use raw data, but should prefe
rably
use structured data to be able to search on payload values and report as appropriate.

8
.9

Monitoring and S
upervision

The EAI should provide a supervisory
station

to m
onitor
technical and business processes

and
messaging flows.

8.10

MT/MX translation

The SWIFT community has agreed that MT and MX will coexist and will both be transported over the
SWIFT network for some period of time.


To support this coexistence period, SWIFT has developed trans
lation rules in human readable

form.
The rules are provid
ed for those MT and MX where equivalence is established and where the
community of users has a need for translation support.


The SWIFTStandards Translation Guide available on
www.swift.com/standards

provide
s all the
necessary information and rules to translate a particular MT or MX source message to its equivalent
MX or MT target message. The machine readable rules (in XSLT format)
is available on request.

Translation rules are currently available for:

-

Credi
t Transfer Messages (103 Core and 103 STP to
pacs

MX)

-

Investment Funds (502 and 515 REDM/SUBS NEWM to
setr

MX)

As an optional feature, the EAI should be able to translate these MT to MX messages and MX to
MT using either the human or the machine formats.


Message
processing

requirements


Complete message processing workflow should be made available, including message
creation (with proper ProductList), storage, routing, reception, reconciliation, repair,
exception and duplicate handling, archiving, monito
ring and event logging.


3 levels of reconciliation should be supported


greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
30

9
.
User
Interface

9
.1
Messag
e
Viewer

The Financial EAI
should

be able to browse incoming and outgoing messages in a formatted way. In
particular, FIN messages
should

be
visualized

using

user
-
friendly

GUI

or web browser

where
field
names
are provided to map onto the FIN
tag

fields code.

9
.2 Message Entry

Manual message entry

using a structured message editor

is a feature requested by many customers
.
Field and message validation
shoul
d be provided, and
syntactical
errors should be highlighted to the
user.

Full
-
fledged Message Entry
work
station is not mandated for
the

Label, but wil
l be recognised as value
-
added O
ption.


9
.
3

Message Repair

The financial EAI will allow editing messages
in order to repair them in exceptional cases. This holds
for messages that do not pass validation and need
urgent
repair prior to
send

them to
SWIFTNet
.

Messages manipulation will be restricted with user with dedicated security profile. Actions taken on
m
essages will be logged, and messages will be stored before and after manipulation for audit
purpose.

The message editor will be format aware.
In particular, field
s name

will be expanded, and field options
will be provided depending on expected type (ex: co
de words, dates, BIC look
-
up).

9
.
4

BIC look
-
up

Financial EAI will provide look
-
up facility to BIC and
BICPlusIBAN

Directory. This is to allow to correct
and enrich the messages to ensure format validation (ensure mandatory BIC fields are provided and
corre
ct) and increase STP (optional BIC fields that should be provided to increase automation at
reception side).

9
.
5

Business Activity Monitoring (BAM)

BAM tracks processing chains at both technical and business levels. This dual competence helps
financial ins
titutions to maintain control of their data flows, through detailed views of inter
-
application
data transformation. Through multiple connectors positioned at all levels of the processing chain, BAM
ensures
end
-
to
-
end supervision and monitoring, guaranteein
g complete control of all data flows.


Business Transaction is made of messages flowing form back
-
office to SWIFT (ex: Paymen
t initiation)
and back from SWIF
T to Back
-
office (ex: Payment confirmation). Message events (
message
gene
rated, validated, repaired
, sent
, ack
nowledged
, delivered, reconciled) can be tracked and
displayed in dashboard for monitoring purpose. Rules can be generated to associate alarms to some
events (ex: message
DelN

note received after 3 days).

Reports should b
e generated.


BAM is recommended but not mandated at this point in the EAI program.

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
31

9
.6
User Interface
requirements


Message Viewer and Repair station will be provided. It will include a BIC look
-
up to fill in the
correspondent fields.

Full
-
fledged messa
ge entry station is not mandated, but recognised as value
-
added label
option.


10. Ma
rketing

and Sales

C
ollaboration in terms of administrative and marketing information

is requested. In particular the EAI
Partner

should provide
SWIFT under non
-
disclos
ure agreement with
:



A list of at least
five

live customers

that
actively

use

the Financial EAI to connect to SWIFT. At
least two of the
se

customers
should

be
FIN enabled.



A

list of
all
customers

active
in

the

finance

secto
r. The list should provide institu
tion name
s
,
location
s
, and an overview of the integration s
cope (domain, features,
and sites
) for the present
and previous year.



A product roadmap for
2008

and 200
9

containing
the
plans for further
EAI development
,
SWIFTSolutions

support and new releases.



A complete set of
EAI suite

documentation, including features overview, SWIFT adapters,
workflow engine capability and user manuals.



A dedicated web page on
Partner

web site for the SWIFTReady label.

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
32

11.
Label
2008

Summary

The required features for
2008

L
abel are provided in the following synopsis.



Dimension

Feature

Label

Optional

Messaging
Protocols

FIN

FIN over SAA (AFT
and

MQSA)


InterAct

SAA support

Any Format (MX, FpML, XML)

SAG support for RT (send and
receive payload) and SF (push
and pull mod
e)

FpML validation

FileAct

RT (Send and Fetch files)

SF (push and pull)

FTA
or

FTI support

Bulk Payment Rule Book

SAG RAHA or MQHA


Standards

MT

All MT support


MX

Well
-
formatted XML

Generic MX Rule book (MVAL)

Rule Book for E&I, Funds, Cash
Reporting, Proxy Voting

ISO 15022

Data Dictionary for MT messages

Use SWIFT DD for internal data
representation

ISO 20022

Data Dictionary for MX messages

Use ISO 20022
to model business
rules and business transaction

FpML

Schema Validation

Semantic validation

Connectivity

SAA 6.0

(6.2)

AFT
and

MQSA for MX and MT
messages

Support XML Format V2

SAA for FpML

ADK support

SAG
6.1

FTA or FTI for FileAct


RAHA
or

MQHA for
all InterAct
and FileAct mode

WSHA support for InterAct

Message
Validation

MFVR


All Message Format validation Rules
(also named network rules) for latest
Standards edition (
SRG 2007
)


MT Usage
Rules

All MT Usage rules


STP
Guidelines

All STP Guide
lines


Market
Practices

Demonstrate Market Practice rules easy
support capability

Support SMPG rules

Support ISO15022 Market
Practices

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
33

Dimension

Feature

Label

Optional

MX

Well formed XML schema, XML facets
validation

Generic Validation rules checked


Reference
Data

BIC Directory

B
IC Directory

look
-
up and message
validation

BIC download automation

BICPlusIBAN

Validate BIC and IBAN

Repair/enrich msg with BIC/IBAN

SEPA
Routing

Validate Routing codes


Message
Processing

Message
creation

Generate M/MT message header and
payload fr
om files and DB records.

Fill in ProductList


Routing

Content based routing (envelope and
payload)


Reception

Debulk and parse MT and MX


Reconciliation

All Notifications (Information,
Transmission and Delivery) reconciled
with original messages in
EAI repository


Repair

Manual Repair

Full Automated Repair for STP
compliance

Duplicate

Handle Duplicate checking and Retry


Log and
archive

Log events and archive messages


Monitoring

Message Monitoring station


MT
-
MX


MT
-
MX translation

User

Interface

Viewer

MT and MX message browser

Web
-
based GUI

Entry

Not required

Message entry station

Repair

Manual repair station

Fully
-
fledged Message Repair
Station

BIC look
-
up

BIC search interface


BAM

Not mandated

Business Activity Monitoring for

message flow control and alarms
management

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
34

Glossary

Term

Definition

ACK

The term used in communication protocols to acknowledge that one party has correctly
received the information sent by another party. Issuance of an ACK does not indicate that the
i
ssuer accepts the business content of the information that it has acknowledged

ACH

Automated Clearing House, ensuring the clearing of payments messages.

AI

Alternative Investments.
A
SWIFTSolution using FpML format

API

A set of formalised software call
s and routines that other applications can reference.
Programs reference an application's API to invoke the functionality of that application

BAM

An application that analyses, reports in real time, and alerts of significant business events. It
gathers dat
a, key performance indicators, and business events from multiple applications,
and consolidate them in dashboards and reports

BIC

A code used in automated processing. This code unambiguously identifies a financial
institution, or an entity within a financ
ial institution. The ISO 9362 standard specifies the
elements and the structure of a BIC. A BIC consists of either eight (BIC8) or 11 (BIC11)
contiguous characters. These characters, comprise either the first three, or all four, of the
following components
:
bank code
,
country code
,
location code
, and
branch code
.

So far,
SWIFT has issued 86,000 BIC.

BIC Directory

The SWIFT directory that lists the
Bank Identifier Codes

(BIC)

that SWIFT has registered
according to the ISO 9362 standard, and the names and addresses of the corresponding
entities. It also contains additional information, for example, the
market infrastructures

in
which the entities participate. The scope of the additional information varies according to the
version of the directory. As from
2008
, the BIC Directory will be updated

on a monthly basis
and available for download on
www.swift.com

> Ordering & Support > Ordering.

BIC Plus
Database

The SWIFT directory that lists identifiers that the financial industry recognises (for ex
ample,
Bank Identifier Codes

(BIC)
,
CHIPS Universal IDentifiers

(CHIPS UID)
, and national cleari
ng
codes). BIC Database Plus provides the identification codes, and the names and addresses
of the corresponding entities

BPM

Business Process Management
-

Software that enables modelling, integration, monitoring,
and optimisation of business process flow
s, crossing application, company boundaries or
human interaction.

Bulk Payment

SWIFTSolution supporting low value payment through SWIFTNet FileAct. Service
Description is available at
https://www2.swift.com/uhbonline/books/protected/en_uk/2/snbpsd/index.h
tm

CAG

Corporate Access Group.
New SWIFT corporate access model, approved by SWIFT
board in 2006 to offer a simplified participation process for corporates

Cash
Reporting

SWIFTNet Cash Reporting is a SWIFTSolution that enable the exchange of real
-
time

information on cash held in accounts maintained at various counterparties

CCI

Common Communication Interface for Euroclear CSD and ICSD

Delivery
Notification

A system
-
generated message (MT 011) that confirms that the system has effectively
delivered a m
essage for which the user has requested the
delivery monitoring

feature. The
notification provides the date and time of delivery.

DMZ

Demilitarized zone
-

A small network
that is located between a user's internal local area
network and one or more external networks. On both sides, firewalls or other traffic filters
protect the small network.

E&I

SWIFTNet Exceptions and Investigations. A SWIFTSolution

EAI

Enterprise Applic
ation Integration

FI

Financial Institution
. This includes but is not limited to banks, brokers, investment managers,
payment and securities infrastructures.

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
35

Term

Definition

FIN Message
Structure

FIN messages have the following general structure:

{1: Basic Header Block}

{2: Application Header Block}

{3: User Header Block}

{4: Text Block or body}

{5: Trailer Block}

Blocks 3, 4 and 5 may contain sub blocks or fields delimited by field tags.

Block 3 is optional. Many applications populate this with a

reference number so that

the Ack
.

can be used for reconciliation purposes
.

FileAct

An automated SWIFTNet messaging service that SWIFT has designed to enable customers
to exchange files. SWIFTNet FileAct supports both interactive and store
-
and
-
forward modes.
It is particularly s
uited for the exchange of large volumes of data.

FXMM

Foreign eXchange and Money Market

Host Adapter

The software that handles the necessary conversions (protocol, data format, security, and
transport) between two messaging paradigms (for example, WebSph
ere MQ and
SWIFTNet
InterAct
).
SWIFTAlliance Gateway

(SAG)

offers host adapters to facilitate the inte
gration of
applications with SWIFTNet

ISO20022

A standard created in 2004 to support the development of all financial messages, using a
business
-
modelling methodology and an XML syntax. UNIFI stands for UNIversal Financial
Industry message scheme. SWIFT i
s the UNIFI registration authority. Candidate UNIFI (that
is, ISO 20002) messages are those developed in compliance with UNIFI.

ITB

SWIFT network domain that vendors and developers use to test applications or interfaces
before deployment on the SWIFT's p
roduction network

Market
Initiative

Projects initiated by the financial industry to support the move towards single and regulated
market. Examples are TARGET2, Giovannini, MiFID, SEPA.

Market
Practices

The geographical, functional, and sectorial agreemen
t about how standards may be used in
a specific business scenario, for a specific market, to guarantee efficient execution of a
financial transaction

Messaging
Operations
Guide

SWIFT manual describing the operational requirement for SWIFTNet InterAct , Fi
leAct and
Browse. It is included in SWIFT UHB, and should be
strictly

adhered to

MFVR

Message Format Validation Rules
-

The document that provides complete information about
the validation procedures that the SWIFT network applies to the text part (block
4) of the FIN
user
-
to
-
user input messages.

For more details, see the Standards volumes of the UHB.

MIC

Market Identification Code. A code allocated by a Registration Authority under an
international identification scheme, as described in the latest editi
on of the international
standard ISO 10383, which specifies a universal method of identifying exchanges, trading
platforms and regulated or non
-
regulated markets as sources of prices and related
information in order to facilitate automated processing

MQSA

MQSeries adapter for SWIFTAlliance Access

MQSeries

Messaging middleware from IBM that allows programs to communicate with each other
across all IBM platforms, Windows, VMS and a variety of Unix platforms. Introduced in 1994,
it provides a common programm
ing interface (API) that programs are written to. The MQ
stands for Message Queue. Now renamed WebSphere MQSeries

MT

FIN message Type. A specific type of SWIFTStandards message that is expressed in
SWIFT's proprietary syntax and identified by a 3
-
digit nu
mber.


MX

XML messages designed using IS20022 methodology

NAK

Negative Acknowledgment The rejection of a message input to a SWIFTNet messaging
service. An error code indicates the reason for the rejection.

PDE

Possible Duplicate Emission


flag added in

message envelope when attempting new
transmission after failure from previous attempt.

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
36

Term

Definition

PDU

Protocol Data Unit. Basic unit of information that is exchanged between

an

EAI and SAA. It
includes
a
business payload

(message, report, status)

wrapped into

an

e
nvelope that carries
address
es
, security, format and validation level information
.

RDBMS

Relational Database Management Systems

RT

Real
-
time. One of the modes used by SWIFTNet Interact and FileAct

SAA

SWIFTAlliance Access


SWIFT Interface for MT and M
X messages

SAG

SWIFTAlliance Gateway provides centralised, automated, and high
-
throughput integration,
with in
-
house applications and service
-
specific interfaces. SWIFT has designed SAG to
enable customers to concentrate messaging flow of messages between

SWIFTNet and
remote financial applications over IP or WebSphere MQ. It is an interface solution for
handling InterAct and FileAct exchanges, but also FIN through the SAA

SCORE

Standardised Corporate Environment


SWIFTSolution for the Corporate, involvin
g Cash
Management, Treasury and Payment initiation messages

SF

Store&Forward mode .One of the modes used by SWIFTNet
Inte
r
Act

and FileAct

SOAP

Simple Object Access Protocol.
A lightweight protocol used to exchange XML
-
based
messages over a computer netwo
rk, using HTTP or other web
-
based protocols.

STP

Straight
-
through Processing.
The handling of a message without resort to manual
intervention or message repair (except for policy), such that it is entered only once.
Thereafter, the system processes it au
tomatically for the rest of the cycle.

SWIFT Central
Services

SWIFT operations centres runs a series of services ranging form Store&Forward queues for
FIN, Interact and FileAct, to security infrastructure, message validation, archiving, and
routing.

SWIF
TSolution

SWIFTNet provides a complete range of end
-
to
-
end solutions covering every aspect of
financial services processing (standards rule book, messaging). These include:

Payments & cash manageme
nt
,
treasury & derivatives
,
trade services
,
securities pre
-
trade/trade, pre
-
settlement, clearing & settlement, custody services and reporting
, alternative
investments
,

Transmission
Notification

The Acknowledgment sent by SWIFT Central services can be transmitted to the EAI as a
Transmission Notification

TSU

Trade Service Utili
ty. The SWIFTNet Trade Services Utility is a collaborative centralised
matching utility designed to help banks meet the supply chain challenge. Banks build
individually on the core functionality of the TSU to offer competitive services complementary
to the
ir existing offering.

UHB

SWIFT User Handbook
. The set of documents,
regularly
amended, that constitutes a
contractual basis for the operational relationship betw
een SWIFT and any SWIF
T user. It
includes all standard messaging.



greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
37

Annex A


MT Messages to support

The list of MT messages that will be target of the qualification is as follows:


MT

Description

101

Request For Transfer

102 and 102+

Multiple Customer Credit Transfer

103

and 103+

Single Customer Credit Transfer

104

Direct Debit and Request for Debit Transfer Message

105

EDIFACT Envelope

110

Advice of Cheque(s)

111

Advises or confirms the issuance of a cheque to the drawee bank

112

Status of a Request for Stop Payment

of a Cheque

190

Advice of Charges, Interest and Other Adjustments

191

Request for Payment of Charges, Interest and Other Expenses

192

Request for Cancellation

195

Queries

196

Answers

198

Proprietary Message

199

Free Format Message

200

Financial In
stitution Transfer for its Own Account

201

Multiple Financial Institution Transfer for its Own Account

202

General Financial Institution Transfer

203

Multiple General Financial Institution Transfer

204

Financial Markets Direct Debit Message

205

Financ
ial Institution Transfer Execution

210

Notice to Receive

290

Advice of Charges, Interest and Other Adjustments

292

Request for Cancellation

295

Queries

296

Answers

298

Proprietary Message

299

Free Format Message

300

Foreign Exchange Confirmation

3
04

Advice/Instruction of a Third Party Deal

305

Foreign Currency Option Confirmation

320

Fixed Loan/Deposit Confirmation

321

Instruction to Settle a Third Party Loan/Deposit

330

Call/Notice Loan/Deposit Confirmation

340

Forward Rate Agreement Confirma
tion

341

Forward Rate Agreement Settlement Confirmation

350

Advice of Loan/Deposit Interest Payment

360

Single Currency Interest Rate Derivative Confirmation

361

Cross Currency Interest Rate Swap Confirmation

362

Interest Rate Reset/ Advice of Payment

380

Foreign Exchange Order

392

Request for Cancellation

395

Queries

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
38

MT

Description

396

Answers

398

Proprietary Message

400

Advice of Payment

410

Acknowledgement

412

Advice of Acceptance

420

Tracer

422

Advice of Fate and Request for Instructions

450

Cash Lette
r Credit Advice

456

Advice of Dishonour

490

Advice of Charges, Interest and Other Adjustments

498

Proprietary Message

500

Instruction to Register

502

Order to Buy or Sell

508

Intra
-
Position Advice

509

Trade Status Message

513

Client Advice of Execu
tion

515

Client Confirmation of Purchase or Sale

517

Trade Confirmation Affirmation

518

Market
-
Side Securities Trade Confirmation

527

Triparty Collateral Instruction

535

Statement of Holdings

536

Statement of Transactions

537

Statement of Pending Tr
ansactions

538

Statement of Intra
-
Position Advices

540

Receive Free

541

Receive Against Payment

542

Deliver Free

543

Deliver Against Payment

544

Receive Free Confirmation

545

Receive Against Payment Confirmation

546

Deliver Free Confirmation

547

D
eliver Against Payment Confirmation

548

Settlement Status and Processing Advice

558

Triparty Collateral Status and Processing Advice

559

Paying Agent's Claim

564

Corporate Action Notification

565

Corporate Action Instruction

566

Corporate Action Confirmation

567

Corporate Action Status and Processing Advice

568

Corporate Action Narrative

576

Statement of Open Orders

578

Settlement Allegement

586

Statement of Settlement Allegements

590

Advice of Charges, Interest and Other Ad
justments

595

Queries

596

Answers

598

Proprietary Message

600

Precious Metal Trade Confirmation

601

Precious Metal Option Confirmation

604

Precious Metal Transfer/Delivery Order

605

Precious Metal Notice to Receive

606

Precious Metal Debit Advice

607

Precious Metal Credit Advice

608

Statement of a Metal Account

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
39

MT

Description

700

Issue of a Documentary Credit

701

Issue of a Documentary Credit

705

Pre
-
Advice of a Documentary Credit

707

Amendment to a Documentary Credit

710

Advice of a Third Bank's or a Non
-
B
ank's Documentary Credit

711

Advice of a Third Bank's Documentary Credit

720

Transfer of a Documentary Credit

730

Acknowledgement

732

Advice of Discharge

734

Advice of Refusal

740

Authorisation to Reimburse

742

Re
-
imbursement Claim

747

Amendment to

an Authorisation to Reimburse

750

Advice of Discrepancy

752

Authorisation to Pay, Accept or Negotiate

754

Advice of Payment/Acceptance/Negotiation

756

Advice of Re
-
imbursement or Payment

760

Guarantee

767

Guarantee Amendment

768

Acknowledgement of
a Guarantee Message

769

Advice of Reduction or Release

791

Request for Payment of Charges, Interest and Other Expenses

795

Queries

798

Proprietary Message

800

T/C Sales and Settlement Advice [Single]

801

T/C Multiple Sales Advice

802

T/C Settlement
Advice

900

Confirmation of Debit

910

Confirmation of Credit

920

Request Message

935

Rate Change Advice

940

Customer Statement Message

941

Balance Report

942

Interim Transaction Report

950

Statement Message

960

Request for Service Initiation Messag
e

961

Initiation Response Message

962

Key Service Message

963

Key Acknowledgement Message

964

Error Message

970

Netting Statement

971

Netting Balance Report

972

Netting Interim Statement

973

Netting Request Message

991

Request for Payment of Charg
es, Interest and Other Expenses

995

Queries

996

Answers

998

Proprietary Message

999

Free Format Message

greasyservant_57840fef
-
48a5
-
4ba7
-
92b8
-
70628eebc5ee.doc


Page
40