Re: A Quick Introduction to UBL Oriented to Payment Solutions Designers

This work-in-progress is now posted on the CG wiki:
https://www.w3.org/community/webpayments/wiki/A_Quick_Introduction_to_UBL_Oriented_to_Payment_Solutions_Designers

Joseph Potvin
On behalf of DataKinetics http://www.dkl.com
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983

On Tue, May 26, 2015 at 12:21 PM, Joseph Potvin <jpotvin@opman.ca> wrote:

> Hello all,
>
> I've prepared the following explanation of the complementary roles of ISO
> 20022 and UBL for structuring and undertaking of electronic payment by any
> means. I also point to a few particular segments of a UBL instructional
> video produced by OASIS/UBL TC co-chair Tim McGrath, which relate directly
> to payment.
>
> Hope you find this draft useful.
>
> This text should probably be placed on the wiki. Perhaps one of the
> editors can point me to where exactly you prefer it to go, and I'll post it
> there for refinement. I'll be using some of this text for a published
> article in a trade journal soon, so early feedback is invited in the
> meantime.
>
> I've been working on this text with the two co-chairs of OASIS/UBL TC, Ken
> Holman & Tim McGrath. Hopefully this version has things correctly stated in
> relation to UBL, but all errors of interpretation are mine. This has not
> yet been reviewed by anyone thoroughly familiar with ISO/TC 68, so various
> aspects below might need correction on that front.
>
> Regards,
>
> Joseph Potvin
> On behalf of DataKinetics http://www.dkl.com
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca
> Mobile: 819-593-5983
>
>
> *A Quick Introduction to UBL Oriented to Payment Solutions Designers*
>
> Joseph Potvin, Draft v0.2 for Comment, 26 May 2015.
> Acknowledgements to Ken Holman & Tim McGrath, Co-Chairs, OASIS/UBL TC for
> review and suggestions. Remaining errors are mine.
>
> CONTENTS
> 1. Scope
> 2. Flexibility & Evolution
> 3. Relationship with ISO 20022
> 4. "Great Payment Set-Up": The Movie Trailer
>
> *1. Scope*
>
> Universal Business Language (UBL) is a royalty-free library of standard
> electronic business documents designed to make electronic commerce more
> efficient and precise, using new or existing contracting, purchasing,
> legal, auditing and records management systems. UBL has been an OASIS
> standard for more than a decade, and now it is on track to approval in 2015
> as ISO/IEC 19845. The scope of UBL addresses the e-commerce use-cases of
> sourcing; ordering; fulfilling; billing; and arrangement for payment
> between payees and payers.
>
> UBL is free/libre/open through OASIS. Its barrier to entry is not cost or
> restrictions, but rather its overall volume and complexity. This is
> inevitable because e-commerce needs to be: (a) computationally
> well-structured; (b) un-restrictive of market freedoms and preferences; and
> (c) flexible to a hodgepodge of evolving laws across a matrix of
> jurisdictions. That's a tall order! Furthermore, UBL has been evolving for
> a decade to accommodate more e-commerce contexts and functions. Today it
> encompasses 65 different e-commmerce document schemas, comprised of 229
> re-usable components, and it includes a formal methodology for further
> customization.
>
> *2. Flexibility and Evolution*
>
> Fortunately, UBL was designed on an 80/20 principle. Your working
> assumpting can be that 20% of UBL suits 80% of your requirements for the
> sourcing, ordering, fulfilling, billing and payment arrangements in any
> particular e-commerce system. The purpose of this short note is to assist
> in orienting you in locating the 20% of the specification that can get you
> 80% of the way to where you'd like to be.
>
> The authors of UBL have anticipated that you would want to customize UBL
> when designing any particular e-commerce solution. Therefore a UBL
> customization methodology is integral to the standard. Customization can
> involve restriction (i.e. cherry-picking the parts of the UBL standard that
> you want) and/or extension (grafting on a new branch).
>
> When you take the mandatory parts of UBL with just your cherry-picked
> elements, you get an implementation that is "conformant" with the standard.
> That's to say, your subset of the whole will fully validate as an
> implementation of UBL. It is rare that extensions would be necessary, since
> considerable flexibility is already built into the standard.
>
> If required however, companies throughout a particular supply chain or
> across an industry can define their own extensions to UBL without degrading
> the interoperability of their solution with other UBL-conformant systems.
> Extensions that do not disturb UBL schema-validity are still UBL
> conformant. Your extension items, of course, will only interoperate with
> those same extensions incorporated into other systems. Extension packages
> can be distributed independently. Improvements with potential broader
> utility could also be shared through the wider UBL community site.
> http://ubl.xml.org/
>
> If the UBL Technical Committee determines that certain shared extensions
> would help in meeting widely experienced real-world needs, they may chose
> to incorporate these into future versions of the standard. So if there's a
> remote possibility that an extension you're developing could be more widely
> distributed at some future date, it's wise to stick to UBL's recommended
> naming conventions and design rules. This approach also facilitates
> security audits, issue response, and on-boarding of technical personnel.
>
> *3. Relationship with ISO 20022 (Universal financial industry message
> scheme)*
>
> UBL addresses a payee's and payer's information requirements to set up a
> payment event, as well as their information requirements following a
> payment event. But UBL does not address the multi-stage payment event
> itself. That's the role of ISO 20022 (Universal financial industry message
> scheme) and related financial industry standards.
>
> The outer threshold of UBL in the domain of payments occurs precisely
> where an e-invoice presents all the information that an e-wallet requires
> to activate the translocation with another e-wallet of a specified
> financial entitlement or obligation. UBL structures that information for
> precise retrieval. UBL does not specify the method by which that
> information is conveyed to the e-wallet or to the payments system beyond.
>
> A good way to think about these complementary standards is in terms of who
> they are for: UBL structures communication between buyers and sellers, and
> ISO 20022 structures communication with and amongst financial entities.
> Members of both these standards' Technical Committees share a general
> consensus that the 'upstream' processes which prime a payment are well
> defined by UBL, and the 'downstream' processes that perform the payment are
> well defined by ISO 20022. The final upstream node is the e-invoice which
> 'speaks' UBL to businesses. The first downstream node is the e-wallet which
> 'speaks' ISO 20022 to financial entities. The information package which
> arcs from the upstream node to the downstream node needs to meet all the
> requirements defined by those downstream processes. In other words: ISO
> 20022 messages originate from UBL invoices. Some of the components within
> UBL are: Currency, Payment and Tax, but inside UBL these can be thought of
> in future tense, as Currency "to be used", Payment "to be dispatched", and
> Tax "to be dispatched".
>
> UBL standardizes 65 e-commmerce document types, because actual documents
> are intended to have permanence as evidentiary artifacts of agreement
> amongst parties. ISO 20022 standardizes only a message "scheme" without
> specifying the various message types, because messages are transitory, and
> they evolve with the diversity of payment systems in operation. For
> convenience however, the ISO 20022 community does maintains a catalogue of
> message types structured according to the ISO 20022 standard. However that
> catalogue is not intrinsic to the standard.
>
> In addition to being mutually complementary, UBL and ISO 20022 each evolve
> within a much wider set of other complementary standards. For example, the
> OASIS/UBL Technical Committee has worked closely with an OASIS Technical
> Committee called TaxXML, to ensure that UBL can accommodate the information
> requirements of a variety of tax regimes. That group is comprised mainly of
> governmental representatives working with the OECD. UBL currently supports
> tax rules associated with attributes of the parties, attributes of the
> items traded, and/or attributes of the transaction.
>
> *4. "Great Payment Set-Up": The Movie Trailer*
>
> Recently Tim McGrath, who Co-Chairs the OASIS UBL (ISO/IEC 19845)
> Technical Committee, produced a set of useful instructional videos about
> UBL. His whole set of videos totals more than an hour and a half. They are
> rather densely-packed with information, so to save busy designers of
> payment solutions time in understanding how UBL can be employed to advance
> payment systems design, I recommend the following short segments from the
> video series which are the most relevant to payment processes, totalling 20
> minutes:
>
> Payment information (24:10-to-28:46) in "Understanding the UBL Data
> Structures"
>
> https://www.youtube.com/watch?v=JVMRK4pHjoQ&list=PLVo0aPE_w8hrzPB_nmVtIzfCNleNFiSWd&index=4
>
> Ordering, invoicing and payment information (3:00-to-5:15 and
> 7:10-to-9:50) in "UBL for Procurement"
>
> https://www.youtube.com/watch?v=-Z6Q_g3CGXM&index=5&list=PLVo0aPE_w8hrzPB_nmVtIzfCNleNFiSWd
>
> Tax information (30:00-to-35:55) in "Understanding the UBL Data Structures"
>
> https://www.youtube.com/watch?v=JVMRK4pHjoQ&list=PLVo0aPE_w8hrzPB_nmVtIzfCNleNFiSWd&index=4
>
> Restricting (1:46-to-5:25) and extending (5:25-to-6:50) in "UBL
> Customization"
>
> https://www.youtube.com/watch?v=OMFA9nfIiqw&index=7&list=PLVo0aPE_w8hrzPB_nmVtIzfCNleNFiSWd
>
> ***
>
> Joseph Potvin
> On behalf of DataKinetics http://www.dkl.com
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca
> Mobile: 819-593-5983
>
>


-- 
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983

Received on Tuesday, 26 May 2015 19:00:01 UTC