A Quick Introduction to UBL Oriented to Payment Solutions Designers

From Web Payments
Jump to: navigation, search

Joseph Potvin, Draft v0.3 for Comment, 26 May 2015.

Acknowledgements: The author wishes to thank Ken Holman and Tim McGrath, Co-Chairs, OASIS/UBL TC for review and suggestions. Remaining errors are the author's.


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.

Flexibility and Evolution

Fortunately, UBL was designed on an 80/20 principle. Your working assumption 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.

If the UBL Technical Committee determines that certain shared extensions would help in meeting widely experienced real-world needs, they may choose 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.

Relationship with ISO 20022

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-depository requires to activate the translocation of a specified financial entitlement or obligation with another e-depository. UBL structures that information for precise retrieval. UBL does not specify the method by which that information is conveyed to the e-depository nor 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-depository 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 the ISO 20022 community 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.

"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: