A Quick Introduction to UBL Oriented to Payment Solutions Designers

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