Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
© XMLdation 2014
Milan Breakfast
Seminar
21st May 2014
Juha Keski-Nisula, CEO
e:Juha.keski-nisula@xmldation.com
t: +358 40...
© XMLdation 2014
XMLdation Company
• XMLdation Oy
• Finnish company, established in September, 2009
– Offices in: Helsinki...
© XMLdation 2014
XML Technology Market Revolution
2012 - 2020
© XMLdation 2014
Payment Validation
Account Report Simulation
XMLdation Service for ISV/Corporates
 Instant response of v...
© XMLdation 2014
End-to-End Integration Testing
Outgoing Payments
1. Test &Validate
• Structure & Content
• External code ...
© XMLdation 2014
Customers and Partners
© XMLdation 2014
Integration testing
• API interface
• To Service
• Extrenal Databases
• Big File Testing
Automated Docume...
© XMLdation 2014
DEMO
© XMLdation 2014
Q&A ?
© XMLdation 2014
Challenges in managing XML Payments Standards
Paola Baldizzone
VP Senior Product Manager
GTB Payments Development
Milano, ...
2
 Once upon a time there was XML
 Is XML a real standard?
 UniCredit approach to harmonization of the standards
 Conc...
3
To cut a long story short
XML (eXtensible Mark-up Language) is a syntax to encode documents or
messages:
■ created in th...
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 b...
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 ...
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...
8
Payments: the Tower of Babel
Messages cover the end-to-end payments chain:
■ customer to bank (pain msgs)
■ bank to bank...
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 o...
… and to SDD schema
Tratta InterbancariaTratta Cliente-Banca
DS-03 Customer to bank Collection
DS-04 The inter-bank Collec...
12
Is ISO 20022 the real "lingua franca"?
In SEPA environment there is a number of "standards"
■ ISO 20022: the mother of ...
13
Harmonization or fragmentation?
The EPC guidelines on the use of SEPA data formats are:
■ not mandatory, only recommend...
14
Customer needs
This multilanguage environment is adequate for the business of local banks
with retail/small business/co...
15
CGI Initiative
The scope of the initiative is to set up implementation guidelines which allow
corporates to send all th...
An example: booking
 The total amount of a bulk (sum of all transactions) is booked as one booking item
 Details in camt...
17
Only what is already harmonized can be harmonized?
■ Different treatments in different Countries
■ Different treatments...
 Once upon a time there was XML
 Is XML a real standard?
 UniCredit approach to harmonization of the standards
 Conclu...
Uniweb
Using our Electronic Banking the client can:
■ Continue using the old CBI formats the converters allow the client t...
EuropeanGate
20
EuropeanGate
ISO XML
V.2ISO XML V.3 CGI
Metaformats
Country formats
EPC IT CBI XmLSEPA
PL PLI
Country form...
 Once upon a time there was XML
 Is XML a real standard?
 UniCredit approach to harmonization of the standards
 Conclu...
22
Harmonization is a challenge
■Country characteristics: special local Country rules/formats (e.g. tax payments)
have to ...
Lessons learned from SEPA XML Migration:
Challenges, Evolution and Benefits
Testing and simulating SEPA Direct Debit Payme...
Topics to cover
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution &
Benefits
2
...
Positioning SEPA e XML
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution &
Bene...
Flat files & XML
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution &
Benefits
4...
The equivalent in XML
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution &
Benef...
Rulebook: why do we use rules?
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolutio...
An overview
• 2 channels: (1) Instruction (2) Report
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration...
How good are your SDD instructions?
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evo...
SDD is more complex than SCT
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution ...
Let us look now at the Returning Flow
• Tessting of this path depends on your counterparty.
XMLdation ⓒ Milano 21-05-2014 ...
Flow of events in SDD presentment:
OK and KO
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challe...
STR – “Straight Through
Reconciliation”
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges,...
STR, first of all understand the info in the
report
• Your reconciliation program must first “understand” the
contents of ...
Phase 2:
Future:
Both
flows
will be in
XML
We will have 2 transition phases
XMLdation ⓒ Milano 21-05-2014 Lessons learned ...
Preparation: obtain test data
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution...
STR: it needs meaningful and reliable
data
• Test data is paramont in successful testing
XMLdation ⓒ Milano 21-05-2014 Les...
A challenge in SDD testing
SIMPLICITY versus EFFECTIVENESS
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Mig...
The traditional approach is:
to clone the production system
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Mi...
Cloning – strengths & weaknesses
Strengths
• Mimic the
production
• E2E (maybe)
• Test also the
infrastrutture
Weaknesses
...
To recapitulate
• XML schemas do not cover the SEPA usage rules
• In SDD testing, beware of the different states
• In migr...
Questions?
Thank you. And...
XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution ...
Upcoming SlideShare
Loading in …5
×

XMLdation seminar Milan 21st may 2014

701 views

Published on

Speakers:
- Unicredit Paola Baldizzone: Challenges in managing XML Payments Standards
- Vee H. Khong: Testing and simulating SEPA Direct Debit Payment Process

  • Be the first to comment

  • Be the first to like this

XMLdation seminar Milan 21st may 2014

  1. 1. © XMLdation 2014 Milan Breakfast Seminar 21st May 2014 Juha Keski-Nisula, CEO e:Juha.keski-nisula@xmldation.com t: +358 400 791 955
  2. 2. © 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
  3. 3. © XMLdation 2014 XML Technology Market Revolution 2012 - 2020
  4. 4. © 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
  5. 5. © 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
  6. 6. © XMLdation 2014 Customers and Partners
  7. 7. © 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)
  8. 8. © XMLdation 2014 DEMO
  9. 9. © XMLdation 2014 Q&A ?
  10. 10. © XMLdation 2014
  11. 11. Challenges in managing XML Payments Standards Paola Baldizzone VP Senior Product Manager GTB Payments Development Milano, 21 maggio 2014
  12. 12. 2  Once upon a time there was XML  Is XML a real standard?  UniCredit approach to harmonization of the standards  Conclusions Agenda
  13. 13. 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.
  14. 14. 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
  15. 15. 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
  16. 16. 6 ISO 20022 Repository
  17. 17. 7 Agenda  Once upon a time there was XML  Is XML a real standard?  UniCredit approach to harmonization of the standards  Conclusions
  18. 18. 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
  19. 19. The SEPA Data Model Fonte: www.sepa.abi.it9 tre
  20. 20. 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)
  21. 21. … 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
  22. 22. 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
  23. 23. 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)
  24. 24. 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
  25. 25. 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
  26. 26. 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  Disadvantage: makes reconciliation more difficult 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  Disadvantage: makes reconciliation more difficult Bulking
  27. 27. 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
  28. 28.  Once upon a time there was XML  Is XML a real standard?  UniCredit approach to harmonization of the standards  Conclusions 18 Agenda
  29. 29. 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
  30. 30. 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
  31. 31.  Once upon a time there was XML  Is XML a real standard?  UniCredit approach to harmonization of the standards  Conclusions 21 Agenda
  32. 32. 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.
  33. 33. 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
  34. 34. 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
  35. 35. Positioning SEPA e XML XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits 3
  36. 36. Flat files & XML XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits 4 0000031071320005 XMLdation Belgium GEBABEBB . 12000BE13210000047239 EUR0000000001000000310713XMLdati. ....
  37. 37. 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.
  38. 38. 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)
  39. 39. 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
  40. 40. 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?
  41. 41. 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 LASTRCUR
  42. 42. 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
  43. 43. 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 CustomerInterbank Instruction (pacs.003) Corporate Creditor bank Debtor bank Debtor B2B Return (pacs.004) ! ! ! !!✔
  44. 44. 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”
  45. 45. 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
  46. 46. 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) Time We’re now here!
  47. 47. Preparation: obtain test data XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits 15 Instructions Test reports
  48. 48. 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
  49. 49. A challenge in SDD testing SIMPLICITY versus EFFECTIVENESS XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits 17
  50. 50. 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 =
  51. 51. 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)
  52. 52. 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
  53. 53. Questions? Thank you. And... XMLdation ⓒ Milano 21-05-2014 Lessons learned from SEPA XML Migration: Challenges, Evolution & Benefits 21

×