SWIFTStandards Developments Update

1
SWIFTStandardsDevelopments - Update

• Marc Pomes Bordedebat
• 15th September, 2004
• Prague Global Payments Forum

September 2004
2
Agenda
Standards development evolution
Status of deliverables
SWIFT2006 standards strategy Standards
convergence Standards coexistence
3
Standards at SWIFT

• Standards development evolution

4
Standards development process Overview
BusinessCase
5
Standards development methodologyStandardisation
through modelling
All institutions have their set of data objects
SWIFT standardises common data objects
6
Standards development evolutionVariants - An
example (in XML)
Bulk credit transfer
Bulk credit transfer
Large remit.
Short remit.
Bulk credit transfer
Bulk credit transfer
STP
STP
Documentation 4 XML Schemas
7
Standards development evolutionOne message
template
Message template
Bulk credit transfer
Bulk credit transfer
Bulk credit transfer
Large remit.
Short remit.
Large remit.
Bulk credit transfer
Bulk credit transfer
Short remit.
STP
STP
STP
STP
Documentation 4 XML Schemas
8
Standards development evolutionVersions (in FIN)

• New versions are
• Generally implicit - there is no indication of
  the new version (its the version before or after
  the Standards Release date)
• Explicit, based on MT number, when there is a
  need for parallel run of new and old version, eg,
  MT54x replace MT52x, MT103 replaces MT100
• Introduced at most on a 12/18-month basis
  (Standards Releases)

9
Standards development evolutionVersions in the
SWIFTNet XML world

• New versions are
• Always explicit, based on a version number
  appended to the Message ID number
• Only one current version, except when there is a
  need for temporary parallel run of new and old
  versions (like today)
• Introduced at most on a quarterly basis

10
Standards development evolutionQuarterly
release windows

• Launch of new SWIFTSolutions at any release
  window, once users ready
• Maintenance of existing SWIFTSolutions (new
  messages or updates to existing)
• To be decided with the users on a case by case
  basis at business solution level
• If same changes impact several business
  solutions, they should be released together at
  the same release window

11
Standards at SWIFT

• Standards deliverables

12
Standards deliverablesCurrent status -
Securities market
Investor
Buyer
Seller
Intermediary
PRE-TRADE/TRADE
TRADE/POST-TRADE
FUNDS
CORPORATE ACTIONS PRE-SETTLEMENT RECONCILIATION
CORPORATE ACTIONS
PRE-SETTLEMENT RECONCILIATION
SECURITIES
Transfer Agent
SETTLEMENT
SETTLEMENT
RECONCILIATION
RECONCILIATION
Custodian
Clearing Agent
I/CSD
Administrator
Fund Manager
XML Portfolio
FIN Portfolio
13
Standards deliverableCurrent status - Payments
market
BULK PAYMENTS
Ordering CustomersFinancial Institution
Beneficiary Customers Financial Institution
Cat 1, 2
REPORTING
INITIATION
REPORTING
C a t 9
MT 1 0 1
Customer-to-bank payment initiation
CASHMANAGEMENT
Ordering Customer
Beneficiary Customer
14
Standards deliverablesCurrent status - Treasury
market
Trading Party
Trading Party
A F F I R M A T I O N S
C O N F I R M A T I O N S
F X - ORDER
RESPO N SE
N E T T I NG R E P O R T S
TREASURY
Spot, Forward, Swap FX Non-Deliverable FX Netting
Reports
Ordering Party (Corporate, Fund Manager)
15
Standards deliverablesCurrent status - Trade
finance market
Buyer
Seller
TRADE FINANCE
GUARANTEES
Buyers bank
Sellers bank
COLLECTIONS
LETTERS OF CREDIT
16
Standards at SWIFT

• SWIFT2006 standards Strategy

17
SWIFT2006 - Standards strategy
Standards convergence and interoperability
Recognised registration authority Adoption of
methodology and tools
ONGOING
Tools Coexistence Injection
SWIFT Standards
IN PROGRESS
DONE
Develop standards and market practices
Adoption and implementation
Develop standards needed to deliver SWIFT2006
market strategies
18
Some implementation aspectsIntegration in
applications today and tomorrow
Machine processable human readable
Object oriented application
UHB
FIN
FIN MTxxx application
FIN
XML
Enterprise database
Application
FIX
Interface and EAI
XML-aware application
XML
19
Standards at SWIFT

• Standards convergence

20
Standards convergence strategy

• Objective
• To enable communication interoperability between
  Financial Institutions, their market
  infrastructures and their end-user communities
• Major obstacle
• There are numerous uncoordinated standardisation
  initiatives looking at financial messages (risk
  of divergence and duplication of efforts)
• Proposed solution
• Define and promote a common ISO/UN-CEFACT
  standardisation approach (methodology, process,
  repository) to be used by these initiatives
• SWIFTs offer
• Offer central Registration Authority (RA)
  services

21
Standards convergence activities

• International Standards Setters (define common
  standardisation approach)
• ISO - 20022
• UN/CEFACT-ebXML
• e-Business MoU (ISO, UN/CEFACT, ITU, IEC)
• Financial Standards Bodies (promote common
  standardisation approach)
• Payments (IFX, ECBS/EPC, TWIST, FED/ANSI/NACHA)
• Securities (SMPG, FIX, MDDL)
• Treasury (FpML, TWIST, ISDA)
• Trade Finance (ICC, Bolero)
• Other Standards Bodies (promote common
  standardisation approach)
• RosettaNet, OAG

22
Registration Authority for ISO 20022
SWIFT
Modelling Group
Business Validation Group
Registration Authority
Data Dictionary
Business Processes Catalogue
23
ISO 200222004 - UNIFI Universal Financial
Industry message scheme
CentralRepository
Interbank payments
ISO20022 Part 1 2
TS20022 Part 3,4,5
SWIFT
www.iso20022.org
FIX
Securities
Data Dictionary
Business request
SWIFT
FpML
Treasury
Business Process Catalogue
Registration Authority
XML message
MDDL
Commercialpayments
ISTH Group
Standards Management Groups
Communities of users developers
Registration Management Group
24
Standards at SWIFT

• Standards coexistence

25
Principles for introducing XML-based standards

• At the pace of the SWIFT community
• Priority to new business solutions
• Launch when ready, quarterly release cycle
• Non-mandatory Closed User Groups
• Standards convergence

26
The issueSome terms and definitions

• Coexistence
• Compatibility agreement on the standard way to
  convert basic data (amount, price, date...),
  between FIN and XML
• Interoperability agreement on the way to use
  data, expressed either in FIN or XML, in support
  of business transactions, without impact on their
  execution
• Transparency the possibility to use either FIN
  or XML without any data loss or even needing to
  know what your counterpart uses

27
The issueSome terms and definitions

• Convergence refers to the migration from the use
  of FIN and XML towards the use of a single
  community-wide agreed standard.
• Translation replacement of a message
  represented in one syntax by an equivalent
  message in another syntax
• Mapping agreement on the way to move relevant
  information from one message in a transaction
  into the subsequent message

28
The issueExample from the financial industry
mapping
mapping
205 (FIN)
910 (FIN)
202 (FIN)
mapping
mapping
103 (FIN)
CashRep (XML)
C2B (XML)
29
The issueExample from the financial industry
Investors
Intermediary
Transfer Agent
RedemptionOrder (XML)
translation mapping
502 (FIN)
502 (FIN)
502 (FIN)
RedemptionOrder (XML)
502 (FIN)
30
The issue What does it mean in reality?

• Some customers want to move immediately to XML
• Some customers want to remain in FIN
• Mixed business transactions must work correctly
  end-to-end
• Communication must remain possible between
  customers (independently of their individual
  choice for FIN or XML)
• Internal applications should not be duplicated
  (or changed) to deal with multiple syntaxes

Coexistence must bridge the gap that is created
because institutions reach their internal
business cases at different moments in time
(potentially years apart)
31
Coexistence - underlying conceptsReverse
Engineering FIN
FIN messages
32
Coexistence - underlying concepts Formalised
mapping rules
33
The scenariosAn overview

• Full FIN support each XML-message gets a
  FIN-equivalent (pro forma option was rejected in
  1999 by XML-choice)
• XML-enveloping for FIN-messages each FIN-message
  can be represented in XML
• XML and FIN combination both FIN and XML support
  a distinct part of the end-to-end transaction
• Full XML support each FIN-message gets a
  properly modelled XML-equivalent. Two options
• Equivalence can be dealt with by institutions
• Equivalence can be supported by central
  translation (implies an important strategic
  consideration by SWIFT)
• Full migration to XML

34
The scenariosFull XML-support options for
translation
Middleware EAI
Business application
Business application
Business application
Business application
Middleware EAI
Business application
Business application
Business application
Business application
35
Key standards messages

• SWIFT is now delivering business standards
• Modelling is the cornerstone of
  standards
  development
• FIN and XML messages will coexist
• SWIFT is now focusing on implementation
• SWIFT facilitates standards convergencein our
  industry

36
uestions

Answers