Post on 06-Aug-2015
© 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)
© XMLdation 2014
DEMO
© XMLdation 2014
Q&A ?
© XMLdation 2014
Challenges in managing XML Payments Standards
Paola BaldizzoneVP Senior Product ManagerGTB 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 ormessages:■ 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 lowcommunication costs, so XML, which is open, general, independent fromplatforms and programming languages, is becoming the principle technology toexchange data between organizations and companies.
4
The great thing about standards is that there are so many tochoose 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 messagestandards 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 creationof ISO 20022 XML: the aim is to allow financial institutions to exchangemassive information between themselves and their clients, using the samemessages structure and interpreting the data in the same way.
Messaging standards provide the definitions of the formats and informationgiven:
■ fields lenght■ character set■ codes■ structure of the fields■ etc
6
ISO 20022 Repository
7
Agenda
Once upon a time there was XML
Is XML a real standard?
UniCredit approach to harmonization of the standards
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 systemsalready did:■ RTGS■ low value domestic systems■ corresponded banking
will these systems migrate to ISO 20022?MT103, MT202, MT950, MT940 areembedded 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 messagesrelated to SCT schema….
Dataset (DS) and corresponding ISO XML messages
Bank to Bank AreaCustomer to Bank Area
DS-01 Customer to bank credittransfer information
DS-02 The Inter-Bank paymentdataset
DS-03 Reject or return credit transfer dataset
DS-04 The Bank to customer credittransfer information
DS-05 The recall of a credittransfer dataset
DS-06 Answer to a recall of credittransfer dataset
ISO messages
Pain.001.001.nn
Pacs.008.001.nn
Pain.002.001.nn
Camt.056.001.nn
Pacs.004.001.nnCamt.029.001.nn
Pacs.002.001.nnPacs.004.001.nn
Camt.052.001.nnCamt.053.001.nnCamt.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 ora Reversal
DS-06 Bank to customer DirectDebit Information
DS-07 The inter-bank Reversal fora 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.nnPacs.004.001.nnPacs.007.001.nnCamt.056.001.nn
Camt.052.001.nnCamt.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 detailedin the Implementation Guidelines
■ ISO 20022 domestic (e.g. XML CBI): the "dialect" spoken in the differentcountries
■ ISO 20022 CGI: the global data format that covers all payments in the C2Barea, 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, thereforethere are various specifications of the standard, which make its application slightlydifferent in different countries, in order to support local needs and to maintain localpractices:■ 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 bankswith retail/small business/corporate customers.But multinational corporates need a higher rate of standardization to properlyrun their business.
■ centralize the payments initiation/processing in one country and send themabroad
■ use of XML format to be executed in the different countries as internationalor 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 allowcorporates to send all their payments around the world and to receive the reporting.This means removing the requirements generated by local business rules, whosecomplexity has to be handled by banks, with the selection of the relevant/necessaryinfo 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, areharmonized, the CGI only gives a framework which allows everything, becauseeliminates every requirement
■ only in SEPA countries XML GCI can replace both the domestic and theinternational 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
SingleBooking
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
GrossBooking
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 Disadvantage: makes reconciliation more difficult
NetBooking
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 Disadvantage: makes reconciliation more difficult
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 tounderstand what works and how: the UniCredit General Country Characteristicsinternal document has the scope to share information in order to have anharmonized 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
Once upon a time there was XML
Is XML a real standard?
UniCredit approach to harmonization of the standards
Conclusions
18
Agenda
Uniweb
Using our Electronic Banking the client can:
■ Continue using the old CBI formats the converters allow the client touse 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 previousversion of the CBI XML to the current (post RB changes)
■ Use the international ISO formats without local characterizations convertersare available from the most widely used ISO formats, also with regard to theconfirmations
19
EuropeanGate
20
Eu
rop
ea
nG
ate
ISO XMLV.2ISO XML V.3 CGI
Metaformats
Country formats
EPC IT CBI XmLSEPA
PL PLI
Country formats
DE DTAZV
HU HUA
RSSRD
…
AT SEPA
DE SEPA
RUXML
TR MT101
Prop.XML
camt.
Pain.002
camt.
Pain.002
Pain.002PPP
IT CBI XmL
SWIFT FILEACT
Once upon a time there was XML
Is XML a real standard?
UniCredit approach to harmonization of the standards
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 andcomprehensible way for customer and sales
■Input vs. Output format: the technical knowledge of Input (e.g. CGI) and Outputformats (local legacies) has to be aligned
■Priorities: customer and product management needs in the different Country leadto different prioritizations
Being a global, proactive and innovative bank, UniCredit accepted the challenge, tobe the partner that customers have come to expect, having themselves to deal withthe 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
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
3
Flat files & XML
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
4
0000031071320005 XMLdation Belgium GEBABEBB .
12000BE13210000047239 EUR0000000001000000310713XMLdati.
....
The equivalent in XML
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
5
Schema, that declares the elements
An “instance” of the schema; an XML file.
Rulebook: why do we use rules?
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & 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
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
7
Instructions
Reports
How good are your SDD instructions?
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & 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
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
9
SCT Fine
SDD
1-off SDD
RECUR. SDD FRST LAST RCUR
Let us look now at the Returning Flow
• Tessting of this path depends on your counterparty.
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
10
Instructions
Reports
Flow of events in SDD presentment: OK and KO
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & 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 Customer Interbank
Instruction (pacs.003)
Corporate Creditor
bank Debtor bank Debtor
B2B Return (pacs.004)
! ! ! ! ! ✔
STR – “Straight Through
Reconciliation”
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & 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.
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
13
Instructions Reports
Accounting Repairs Exception handling . . . End
Phase 2:
Future: Both flows
will be in XML
We will have 2 transition phases
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
14
Instructions (in XML)
Report (in Records Fissi)
Phase 1:
Today: Only 1 part in
XML
Instructions (in XML)
Reports (in XML)
Tim
e
We’re now
here!
Preparation: obtain test data
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
15
Instructions
Test reports
STR: it needs meaningful and reliable
data • Test data is paramont in successful testing
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & 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
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
17
The traditional approach is: to clone the production system
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
18
Message Input Terminal
(Production)
Database
(production) Database
(Test)
Message Input Terminal
(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
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
19
Message Input Terminal
(Production)
Database
(production) Database
(Test)
Message Input Terminal
(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.
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
20
Questions?
Thank you. And...
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits
21