XMLdation seminar Milan 21st may 2014

© XMLdation 2014
Milan Breakfast
Seminar
21st May 2014
Juha Keski-Nisula, CEO
e:Juha.keski-nisula@xmldation.com
t: +358 400 791 955

© XMLdation 2014
XMLdation Company
• XMLdation Oy
• Finnish company, established in September, 2009
– Offices in: Helsinki and Tampere
– Representation in Brussels
• Mission: We support XML migration process and STP development
especially in corporate-to-bank and bank-to-corporate
communication
Bank customers in 10 countries
Users of the XMLdation Service in more than 45 countries

© XMLdation 2014
XML Technology Market Revolution
2012 - 2020

© XMLdation 2014
Payment Validation
Account Report Simulation
XMLdation Service for ISV/Corporates
 Instant response of validation
 No need for real bank accounts
 Same testing process and testing tool
with multiple countries/banks
 Bank specific implementation
 Cost savings in bank customer service
 Enables self service by corporate customers
 Helps error tracking and correction
XMLdation Service for Banks

© XMLdation 2014
End-to-End Integration Testing
Outgoing Payments
1. Test &Validate
• Structure & Content
• External code list
Incoming Reports
2. Simulation processes
• Account Statements
• Payment Status reports
• With R-Messages

© XMLdation 2014
Customers and Partners

© XMLdation 2014
Integration testing
• API interface
• To Service
• Extrenal Databases
• Big File Testing
Automated Documentation
• Rule Documentation
• MIG Generation
• Example Files
• Version Management
Payment Process Simulation
• Mapping
• Visualization of E2E
Process
• Direct Debit Process
Developer Interface
• Reusable Libaries
• Business Rules (XSD)
Management
• Automatic Correction
Looking beyond SEPA
On-Premises setup
• API + JAR
• JAR
• Customer Database
• (Full Service)

Challenges in managing XML Payments Standards
Paola Baldizzone
VP Senior Product Manager
GTB Payments Development
Milano, 21 maggio 2014

2
 Once upon a time there was XML
 Is XML a real standard?
 UniCredit approach to harmonization of the standards
 Conclusions
Agenda

3
To cut a long story short
XML (eXtensible Mark-up Language) is a syntax to encode documents or
messages:
■ created in the 90s by the W3C (World Wide Web Consortium)
■ metalanguage used to create new languages, adding new tags as needed
■ main tool to publish web pages
■ tool that allows to define the structure of documents and data formats, to
exchange information between different systems, in different organizations,
which use different software
Nowadays the Internet is the most widespread net in the world, with low
communication costs, so XML, which is open, general, independent from
platforms and programming languages, is becoming the principle technology to
exchange data between organizations and companies.

4
The great thing about standards is that there are so many to
choose from
But the medal has a reverse side: the fact of being potentially universal implies that,
in certain environments and in certain contexts, some standardization is needed,
otherwise the business cannot be run.
In the world of financial services, there are many standards:
■ Proprietary Domestic Standards
■ EDIFACT
■ Swift Standards (MT messages)
■ XML Standards
■ others?
How can an automated, worldwide, end-to-end chain be set up?
XML ISO 20022 was designed to help the financial industry to create message
standards covering their business processes:
■ a method to develop structured financial messages
■ a way to unify the existing standards

5
ISO 20022
In the financial industry the standard has been set up by ISO, with the creation
of ISO 20022 XML: the aim is to allow financial institutions to exchange
massive information between themselves and their clients, using the same
messages structure and interpreting the data in the same way.
Messaging standards provide the definitions of the formats and information
given:
■ fields lenght
■ character set
■ codes
■ structure of the fields
■ etc

7
Agenda
 Conclusions

8
Payments: the Tower of Babel
Messages cover the end-to-end payments chain:
■ customer to bank (pain msgs)
■ bank to bank (pacs msgs)
■ bank to customer (reporting) (camt msgs)
But if SEPA adopted ISO 20022 as a standard, not all the worldwide payment systems
already did:
■ RTGS
■ low value domestic systems
■ corresponded banking
will these systems migrate to ISO 20022?MT103, MT202, MT950, MT940 are
embedded in the legacy systems of financial institutions
■ maintenance of two systems to manage both kind of messages
■ translate the new formats in the old ones, in order to keep the legacies work,
instead of changing the applications

The SEPA Data Model
Fonte: www.sepa.abi.it9
tre

10
Fonte: SEPA Credit Transfer Implementation Guidelines e www.iso20022.org
The Rulebook provides a detailed description of the messages
related to SCT schema….
Dataset (DS) and corresponding ISO XML messages
Bank to Bank AreaCustomer to Bank Area
DS-01 Customer to bank credit
transfer information
DS-02 The Inter-Bank payment
dataset
DS-03 Reject or return credit transfer dataset
DS-04 The Bank to customer credit
transfer information
DS-05 The recall of a credit
transfer dataset
DS-06 Answer to a recall of credit
transfer dataset
ISO messages
Pain.001.001.nn
Pacs.008.001.nn
Pain.002.001.nn
Camt.056.001.nn
Pacs.004.001.nn
Camt.029.001.nn
Pacs.002.001.nn
Pacs.004.001.nn
Camt.052.001.nn
Camt.053.001.nn
Camt.086.001.nn
(MT942)
(MT940)

… and to SDD schema
Tratta InterbancariaTratta Cliente-Banca
DS-03 Customer to bank Collection
DS-04 The inter-bank Collection
DS-05 Direct Debit Rejection,
Return or Refund of a Collection or
a Reversal
DS-06 Bank to customer Direct
Debit Information
DS-07 The inter-bank Reversal for
a Collection by the Creditor
Messaggi ISO
Pain.008.001.nn
Pacs.003.001.nn
Pain.002.001.nn
Pacs.007.001.nn
Pacs.002.001.nn
Pacs.004.001.nn
Pacs.007.001.nn
Camt.056.001.nn
Camt.052.001.nn
Camt.053.001.nn
(MT942)
(MT940)
11
Bank to Bank AreaCustomer to Bank Area ISO messages
Dataset (DS) and corresponding ISO XML messages

12
Is ISO 20022 the real "lingua franca"?
In SEPA environment there is a number of "standards"
■ ISO 20022: the mother of all standards
■ ISO 20022 EPC: the SEPA data formats specified by EPC to manage SCTs
and SDDs, accordingly to the rules decreed by the Rulebooks, and detailed
in the Implementation Guidelines
■ ISO 20022 domestic (e.g. XML CBI): the "dialect" spoken in the different
countries
■ ISO 20022 CGI: the global data format that covers all payments in the C2B
area, all transaction banks, and all payment systems

13
Harmonization or fragmentation?
The EPC guidelines on the use of SEPA data formats are:
■ not mandatory, only recommended, in the C2B area
■ binding, in the PSP's area (when PSP's are direct participants to the SCT/SDD
schemes):
■ "yellow" fields
■ "white" fields
The implementation guidelines maintain a degree of interpretation, therefore
there are various specifications of the standard, which make its application slightly
different in different countries, in order to support local needs and to maintain local
practices:
■ some info added in the group header (e.g. Spain)
■ some product different from SCT inserted in the format (e.g cheques in Spain)
■ some optional field in the EPC RB made mandatory in the local implementation
rule
■ local XML formats in the C2B area have been released, to accomplish existing
domestic business needs (e.g. CBI, Stuzza, Febelbin standards…)
■ use of ISO codes not in the expected meaning (e.g. SALA in Portugal)
■ use of tags not in the designed way (e.g. URGP in Germany)

14
Customer needs
This multilanguage environment is adequate for the business of local banks
with retail/small business/corporate customers.
But multinational corporates need a higher rate of standardization to properly
run their business.
■ centralize the payments initiation/processing in one country and send them
abroad
■ use of XML format to be executed in the different countries as international
or SEPA or domestic payments
■ local needs and local practices to be satisfied
■ use of XML to receive confirmations (pain.002) and reporting (camt.053-
camt.054-camt.086)
■ bulk booking vs single booking

15
CGI Initiative
The scope of the initiative is to set up implementation guidelines which allow
corporates to send all their payments around the world and to receive the reporting.
This means removing the requirements generated by local business rules, whose
complexity has to be handled by banks, with the selection of the relevant/necessary
info to be forwarded to the various Clearing Houses for the execution of the payment.
So if EPC implementation guidelines give a set of business rule that, if followed, are
harmonized, the CGI only gives a framework which allows everything, because
eliminates every requirement
■ only in SEPA countries XML GCI can replace both the domestic and the
international formats
■ customers are interested in initiating specific products
■ CGI is interested in common rules, while local practices, rules and laws are not
forbidden, but also not taken into consideration:
■ bulk booking flag
■ INTC
■ SALA
■ URGP
■ TAXS

An example: booking
 The total amount of a bulk (sum of all transactions) is booked as one booking item
 Details in camt.054 or in pain.002
 Advantage: saves postings on account and account statement; reduces fees
 Disadvantage: makes reconciliation more difficult
Bulk-
Booking
 Each transaction of the bulk is booked on the account
 Details in account statement (camt.053)
 Advantage: helps reconciliation
 Disadvantage : produces long account statements and, in case, fees
Single
Booking
 The total amount of a bulk is booked
 Rejected transactions (r-messages) are booked in reverse (pain.002-report)
 Advantage: transparency of transactions processed and rejected in the statement
 Disadvantage: increases postings on account and account statement; in case, fees
Gross
Booking
 Only the correctly processed transactions are booked
 Rejected transactions (r-messages) are not booked, reducing the amount (pain.002
report)
 Advantage: allows customer to know rejects (unpaid) before settlement; saves
postings on account and account statement; reduces fees
Net
Booking
 Similar incoming transactions are bundled together and booked in one amount
 Details in camt.054
 Advantage: saves postings on account and account statement; the statement
gathers groups of similar kind of payments
Bulking

17
Only what is already harmonized can be harmonized?
■ Different treatments in different Countries
■ Different treatments in different banks
■ Different treatments in the same bank in different Countries
Necessity to take the picture of the status in the different Countries in order to
understand what works and how: the UniCredit General Country Characteristics
internal document has the scope to share information in order to have an
harmonized approach to the payments management as a Group:
■ products
■ scheme of the products
■ management of conditions
■ service levels
The goal is to build Group implementation rules based on CGI

 Conclusions
18
Agenda

Uniweb
Using our Electronic Banking the client can:
■ Continue using the old CBI formats the converters allow the client to
use the old CBI to generate flows in the SEPA XML CBI format
■ Use the new CBI XML formats the new CBI XML can be used immediately
■ Use previous CBI XML versions converters are available from the previous
version of the CBI XML to the current (post RB changes)
■ Use the international ISO formats without local characterizations converters
are available from the most widely used ISO formats, also with regard to the
confirmations
19

EuropeanGate
20
EuropeanGate
ISO XML
V.2ISO XML V.3 CGI
Metaformats
Country formats
EPC IT CBI XmLSEPA
PL PLI
Country formats
DE DTAZV
HU HUA
RS
SRD
…
AT SEPA
DE SEPA
RU
XML
TR MT101
Prop.
XML
camt.
Pain.002
camt.
Pain.002
Pain.002
PPP
IT CBI XmL
SWIFT FILEACT

 Conclusions
21
Agenda

22
Harmonization is a challenge
■Country characteristics: special local Country rules/formats (e.g. tax payments)
have to be "translated" into the input format and described in a standardized and
comprehensible way for customer and sales
■Input vs. Output format: the technical knowledge of Input (e.g. CGI) and Output
formats (local legacies) has to be aligned
■Priorities: customer and product management needs in the different Country lead
to different prioritizations
Being a global, proactive and innovative bank, UniCredit accepted the challenge, to
be the partner that customers have come to expect, having themselves to deal with
the challenges of the global context.

Lessons learned from SEPA XML Migration:
Challenges, Evolution and Benefits
Testing and simulating SEPA Direct Debit Payment Process
Vee H. KHONG
Milan, 21-05-2014

Topics to cover
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution &
Benefits
2
1. Basics
a. SDD, XML & rules in context
2. Characteristics & complexity of
a. SDD
b. Returning flow
3. Approaches used in testing:
a. SDD
b. Returning flow

Positioning SEPA e XML
Benefits
3

Flat files & XML
Benefits
4
0000031071320005 XMLdation Belgium GEBABEBB .
12000BE13210000047239 EUR0000000001000000310713XMLdati.
....

The equivalent in XML
Benefits
5
Schema,
that declares the elements
An “instance” of the schema;
an XML file.

Rulebook: why do we use rules?
Benefits
6
A_Phrase
Subject
Verb
Preposition
C. object
(1)
Schema,
example of a phrase
Rule:
Conjugation
Rule:
andare in (+ paese)
andare a (+ città)
Phrase-1
Io
andare
a
paese
(2)
A valid XML instance
based on the schema
Phrase-1’
Io
vado
in
paese
(3)
Correct instance with
usage rules (grammar)

An overview
• 2 channels: (1) Instruction (2) Report
Benefits
7
Instructions
Reports

How good are your SDD instructions?
Benefits
8
• Have you addressed all its complexity?
• Are the messages compliant to the usage rules?
• How much time to you spend on error corrections?

SDD is more complex than SCT
Benefits
9
SCT Fine
SDD
1-off
SDD
RECUR.
SDD FRST LASTRCUR

Let us look now at the Returning Flow
• Tessting of this path depends on your counterparty.
Benefits
10
Instructions
Reports

Flow of events in SDD presentment:
OK and KO
Benefits
11
SDD instruction
(pain.008)
Instruction
(pacs.003)
B2B Reject (pacs.002)
Refund
B2B Return (pacs.004)
OK, o
Reject
estratto camt.053
estratto camt.054
rapporto pain.002
Bank -Enterprise CustomerInterbank
Instruction
(pacs.003)
Corporate
Creditor
bank
Debtor
bank Debtor
B2B Return (pacs.004)
! ! ! !!✔

STR – “Straight Through
Reconciliation”
Benefits
12
Source: Gtnews.com article 6 Feb 2014 “Emerging Trends in Straight-Through Reconciliation”

STR, first of all understand the info in the
report
• Your reconciliation program must first “understand” the
contents of the reports in order to match the entries.
Benefits
13
Instructions Reports
Accounting Repairs
Exception
handling . . .End

Phase 2:
Future:
Both
flows
will be in
XML
We will have 2 transition phases
Benefits
14
Instructions (in XML)
Report (in Records Fissi)
Phase 1:
Today:
Only 1
part in
XML
Instructions (in XML)
Reports (in XML)
Time
We’re now
here!

Preparation: obtain test data
Benefits
15
Instructions
Test reports

STR: it needs meaningful and reliable
data
• Test data is paramont in successful testing
Benefits
16
Reconciliation
engine
Today XML ⬌ Flat XML ⬌ XML
Reports
(Flat file)
Report
(XML)
Test data
generator
SDD
Phase 1
Transition
Phase 2
Transition

A challenge in SDD testing
SIMPLICITY versus EFFECTIVENESS
Benefits
17

The traditional approach is:
to clone the production system
Benefits
18
Message Input Terminal
(Production)
Database
(production)
Database
(Test)
(Test)
Message
Processing
Unit =

Cloning – strengths & weaknesses
Strengths
• Mimic the
production
• E2E (maybe)
• Test also the
infrastrutture
Weaknesses
• Complex 
Costly
• E2E calls for the
time and
resources of a
counterparty
• More points of
failure
Benefits
19
(Production)
Database
(production)
Database
(Test)
(Test)
Message
Processing
Unit
(Production)
Message
Processing
Unit
(Test)

To recapitulate
• XML schemas do not cover the SEPA usage rules
• In SDD testing, beware of the different states
• In migration be mindful of the returning flows
• A high STR implies significant saving
• System cloning for testing is heavy and costly.
Benefits
20

Questions?
Thank you. And...
Benefits
21

XMLdation seminar Milan 21st may 2014

Recommended

Recommended

More Related Content

Similar to XMLdation seminar Milan 21st may 2014

Similar to XMLdation seminar Milan 21st may 2014 (20)

Recently uploaded

Recently uploaded (20)

XMLdation seminar Milan 21st may 2014