Both the OFX and IFX protocols will be implemented in XML, an Internet standard approved by World Wide Web Consortium in February of last year. XML (eXtensible Meta Language), a new standard for Web-based billing, promises major improvements, in how information is published on the Web and how data is exchanged among organizations. Will the use of XML in OFX and IFX speed up the industry adoption of a single standard? Is XML the answer to the success of these protocols?
Some Background on Billing Standards
Before we can understand the impact of XML on Internet billing standards, some background on the OFX and IFX standards is needed.
OFX was created by CheckFree, Intuit and Microsoft in the fall of 1996 as a protocol to facilitate the exchange of data for banking, investments, bill payment and bill presentment applications. Several versions have been released since it was first introduced. The latest version, OFX 1.5, is supported by these three companies and by other technology vendors such as Just in Time Solutions, InteliData and Oracle. Currently, OFX is the only open standard for bill presentment.
OFX for Bill Presentment
OFX was originally created for communication between PFMs (Personal Financial Managers, such as Quicken and Microsoft Money) and financial institutions. In the area of bill presentment, OFX was extended to provide support for server-to-server communications. This allowed a biller (or bill presentment service provider, such as CheckFree) to send bill summary information to a consolidator (or to a customer service provider, such as a home-banking website). In OFX 1.5, the support of bill presentment includes the following transactions:
? Sign On — The customer authenticates with the biller or bill presentment service provider.
? Enrollment — The customer enrolls with a bill presentment service provider, and is then able to receive bills.
? Activation — The customer activates bill presentment for a specified billing account. (Customers may have more than one account with a biller and therefore may need to activate each account separately.)
? Bill Summary Request — The customer requests bill summaries of activated accounts. (A customer service provider may also make a request on behalf of a group of customers.) The bill summaries contain the due date of the bill, the biller, the amount due and a URL that points to the bill detail image, usually an HTML page.
? Notification — A customer or customer service provider “notifies” the bill publisher that a bill has been “viewed” by the customer.
OFX and Gold Merge to Become IFX
In early 1998, the OFX consortium teamed up with BITS (Banking Industry Technology Secretariat, a consortium of banks) and IBM’s Integrion in an attempt to merge OFX with Integrion’s Gold standard. While Gold is similar in scope to OFX, the technology is quite different. The resulting effort is the forthcoming IFX specification. The first version of IFX is due in the last quarter of 1998.
An additional industry consortium has created the InteroperaBILL Technical Working Group to solve the interoperability issues surrounding bill presentment and payment. This group will make recommendations for the next release of IFX, due in 1999.
Many industry players treat IFX as the logical next step to OFX. However, the process to complete IFX has been slower than anticipated. The merge has largely been affected by political and personal differences. IFX represents such a big architectural departure from OFX that some feel it was like starting from scratch. There is a general reluctance to reinvent the wheel with no apparent feature improvement. In addition, some technical issues derive from the technical differences between GOLD and OFX.
While IFX is being readied for implementation, the OFX consortium will continue to release new versions of OFX in the interim. Companies who are considering deploying OFX capabilities for bill presentment today will likely have the majority of their investment protected; the portion of the IFX standard that covers bill presentment is based on the OFX bill presentment specification.
What XML Brings to Billing Standards
Currently, OFX formats the transaction data in SGML (Standardized General Markup Language). In contrast, newer versions of OFX will use XML as the standard for describing data. For IFX, the specification will be implemented entirely in XML from the start.
XLM is actually slightly misnamed. It is not a single markup language; it's a metalanguage that lets a user design his or her own markup language. A regular markup language defines a way to describe information in a certain class of documents (for example, HTML). XML defines customized markup languages for many classes of documents, such as bills, purchase orders or product catalogs. It can do this because it's written in SGML, the international standard metalanguage for markup languages.
Since XML was endorsed by the World Wide Web Consortium in February 1998, XML has been considered the language of the future for the Internet. It is designed to solve many problems in existing Internet applications, most specifically the standardized description and interchange of data. Put simply, it is intended to provide a single technical standard for describing documents such as bills.
XML is also superior to HTML (a subset of SGML) in that it allows Web page developers to separate content from presentation. The XML version is not only more computer readable, but the style-definition feature makes it easy to change the presentation of the data without having to affect the data itself.
XML also can store metadata (information about the content) along with the data itself. For example, XML can provide accurate description of billing data — such as the subtotal, tax and total for a bill — apart from defining how the bill looks. Such separation gives users a much more powerful and accurate way to search for information inside documents on the Internet. For example, users may be able to search for all bills that are past due, or for all utility bills.
Metadata also makes it possible for a document to be directed to, and used by, different workflow applications. A Document Type Definition (DTD) specifies the contents for a particular XML document type, such as a telephone bill. In addition, metadata is useful in defining standard protocols for data exchange, as used in electronic commerce.
XML is an open standard designed to be interoperable across platforms and applications. As such, it offers many benefits over SGML. Considerably less complex than SGML, XML is easy to understand and use. XML provides the basis for a common API (application protocol interface) across Web servers, legacy systems, databases and middleware infrastructures. And since XML is positioned as a widely adopted standard, there are many parsers for XML; most are written in Java, the language of choice for Internet applications. An XML document header can contain a DTD, or a DTD subset to supplement the main DTD, allowing a more powerful way to support customized tags (see sidebar). Finally, XML provides a richer type definition for OFX and IFX than the earlier SGML version of OFX.
In addition to OFX, industry organizations are using XML to implement other standard protocols. For example, there is the Chemical Markup Language (CML) to provide a standard way of modeling molecular structures, and Open Trading Protocol (OTP) to facilitate interoperability in electronic commerce.
How Soon Will OFX and IFX Be Widely Adopted?
The use of XML in OFX and IFX, and the widely available tools and parsers for XML, will make it easier for new entrants to Internet billing to implement applications that speak OFX and IFX.
Despite this advantage, three conditions are necessary to successful and wide adoption of the standard:
1) Complete functionalities must be provided by the protocol. OFX is still in its early stages. Although the protocol supports all the necessary transactions for basic bill presentment and payment, some vendors want to add additional capabilities now. (This is evident from the fact that TransPoint is not using interoperable OFX as protocol for communication between its biller integration software (BIS) and TransPoint. According to insiders at TransPoint, the company feels the need to support additional capabilities, such as an area for staging bill detail after the bill has been uploaded to the TransPoint server.)
2) Industry players on all fronts must provide services and software that implement OFX and IFX. Many industry players are moving out of the wait-and-see mode and into development and deployment. Intuit and CheckFree now support OFX in production environments, for biller service provider and consumer service provider respectively. Many more companies are planning pilots and deployment launches of OFX-compatible services through 1999.
3) Industry players must refrain from using proprietary protocols or customized tags. Using proprietary protocols or customized tags defeats the purpose of a standard protocol and prevents interoperability among the players. As an industry, we will all succeed only if consumers can receive a critical number of bills in a single location of their choosing.
At this point, there has been no controversy involving the use of XML. However, since the upgrade to XML from SGML involves a major engineering effort, some industry players are still trying to agree on the timing for the switch-over. Over time, XML will increase the quality, quantity, and interoperability of software for bill presentment. XML will likely play a behind-the-scenes role in enabling standards rather than directly impacting the customer’s ability to deploy advanced functionality today.
Using XML to Implement Customized Tags
An organization that provides a customized client and server that communicate by means of OFX might wish to add new requests and responses, or even specific elements, to existing requests and responses. For example, a bill publisher might want to improve customer service by providing bill payment status information to a consolidator. Although the current version of OFX does not provide this information, the publisher could use the custom tag to do so, without waiting for the next release of OFX. By convention, the custom tags will be in the name of
Glossary
Biller – Company or organization that sends a bill or statement to a customer, usually a request for payment for a product or service.
Biller Payment Provider (BPP) - An agent (usually a financial institution) of the Biller that originates and accepts payments on behalf of the Biller.
Biller Service Provider (BSP)- An agent of the biller that provides an EBPP (electronic bill presentment and payment) service for the biller.
Customer Account Information - Detail field within Remittance Information, usually the account number assigned to that customer by the biller. This can also be used to mean the customer's billing name and address, as well as any other information that the biller uses to identify the customer.
Customer Payment Provider (CPP) - An agent (usually a financial institution) of the customer that originates payments on behalf of the customer.
Customer Service Provider (CSP) – An agent of the customer that provides an interface directly to customers, businesses or others for bill presentment. CSP enrolls customers, enables presentment and provides customer care, among other functions.
Electronic Bill Presentment and Payment (EBPP) - Electronic presentment of customer bills that contain a mechanism that enables the customer to pay the bill.
Interactive Financial Exchange (IFX) - A standard for the exchange of financial data and instructions independent of a particular network technology or computing platform. It builds on previous industry experience, including OFX and GOLD, which are currently implemented by major financial institutions and service providers to enable electronic exchange of financial data between themselves and their customers.
Registration - The process of a biller establishing a relationship with a BSP. Registration is also a process of BSPs and CSPs establishing relationships with each other. It is expected that a BSP and CSP will have a relationship before they exchange any account activation information. It is expected that a biller will have a relationship with a BSP before a CSP will start sending activation requests to a BSP for that biller. It is also possible that the biller will have a relationship with a CSP before that CSP sends activation requests for that biller.
Edward Un is the chief technology officer at Just in Time Solutions Inc. He can be reached by e-mail edu@justintime.com or telephone 415-553-6403.
