Electronic Payment Interoperability Working Group

1
Electronic Payment Interoperability Working Group
OMG Financial domain Task Force

• Meeting Notes - 2/4/04 thru 2/5/04
• Acting Chair - Cory Casanave

2
Mission Statement

• The mission of the OMG Electronic Payments
  Interoperability Working Group is to enable
  greater adoption of electronic payments. The WG
  will achieve its mission by creating and
  publishing electronic payment interoperability
  standards using the Model Driven Architecture
  (MDA) approach . These standards will consist of
  formal models of interoperability between payment
  and business systems in a world where multiple
  protocols and interfaces exist..

3
Forward

• On February 4th and 5th members of the financial
  industry met in the context of the Object
  Management Group (OMG) to explore the formation
  of an initiative to enable greater adoption of
  electronic payments.
• The group formed as a working group of the OMG
  financial domain task force.
• The following are notes from this initial
  meeting.
• Some of the discussion referenced the formation
  white paper OMG document finance/04-02-02

4
Presentations

• Leveraging Financial Payments
• Joe Bugajski, Visa International
• Model Driven Payment Architecture
• Cory Casanave, Data Access Technologies
• Universal Value eXchange (UVX)Project Supply
  Chain Integration
• Micheal Talley, University Bank
• Payment Gateway Architecture
• Ed Seidewitz, Intellidata

5
RosettaNet Example

• Presented by Bill Jetter, Bank of America
• Problem A/R posting manually
• Problem source
• Inconsistent ability of payment networks to carry
  remittance advise data
• Advise goes over net separate from payment (or
  combined)
• Inconsistent practice among bankers in carrying
  remittance info through internal systems
• Inconsistent message standards
• Inconsistent telecom standards

Swift
Buyers Bank
Sellers Bank
ACH
Many others
Credit Advice URI
Payment orderURI
Payment URI
Buyer
Seller
Remittance Advice URI
URI Universal Remittance ID (18 char)
Re-association
6
Candidates for models

• Retail Point of Service (POS)
• Person is paying using either an attended (clerk
  at check-out counter), or an unattended terminal
  at a merchants place of business (self-serve
  gasoline and grocers)
• Person is paying using a remote terminal that is
  not under merchants control (Amazon, JC Penny
  Catalogue, e-payment for taxes)
• Bill Payment Consumers pay a business for a
  work for hire (landscaping), subscriptions
  (Comcast, AOL), utilities (electricity),
  insurance, loans (mortgage)
• Remittance information required
• Payment schedule required
• Penalty schedule required
• Person-to-Person payments (no business involved)
• Direct funds transfer (Wire transfer, Western
  Union)
• Indirect funds transfer (credit card, money
  order, travelers checks)
• Commercial Payments
• T E requires requires supporting details
  (hotel bill, restaurant receipt)
• Purchasing card requires remittance information
  and approval authorities
• Purchase order payment requires contract,
  remittance information, approval authorities,
  delinquency fees
• Systems and services to be explained by each of
  the models
• Payment devices e.g., Wireless PDA (IR),
  Phone (RF or IR) , Proximity (RF) Wired
  Magnetic Strip, Chip, Key Terminal, electronic
  check
• Clearing operation for payment
• Settlement operation for payment
• Authorization for payment

7
4 Corner Bank - Buyer/Seller Details
8
Bank Buyer/Seller Interfaces

• Business
• ERP Solutions (POS Solutions)
• Interfaces
• Direct Deposit/Debit
• Credit Card (online) Transactions
• Bank Statement
• Remittance Advice (between Buyer-Seller)
• Consumer
• Bill Payment/Presentment/Consolidation as Web
  Service or in Personal Finance Software
• Use (subset of) Business Interfaces

9
Bank Buyer/Seller Interfaces

• Many inconsistent Clouds also with one bank
• E.g. Bank Statement does not include info
  electronically submitted in payments
• E.g. Reconciliation of Credit Card Statements
  with submitted credit card charges
• Popular Formats ACH, OFX, SWIFT, etc.
• Problem Banks provide inconsistent sub or
  superset requiring a different interface for
  every bank
• As creating interface is significant cost factor
  when implementing ERP, may determine selection of
  Bank
• Different Interfaces for different Account Types
  (Business/Consumer/etc. Accounts) of one Bank
• Payment Reconciliation
• Remittance Advice between Seller/Buyer rarely
  available
• Need to transmit that info in payment (customer,
  invoice/shipment, remittance reference)
• Pain for Customers is lack of (consistent)
  reference requiring manual reconciliation
• Specific Bank Charges usually have no reference
  to payment

10
Next Step Request for Information

• Discussed options of a white paper, RFI or RFP.
• Resolution Issue an RFI to get information from
  and help with recruitment from the financial
  community
• Intention is to issue at the next OMG meeting,
  April 26th. RFI must be on the OMG server by
  April 5th
• Draft to be prepared within 2 weeks editor not
  identified
• Follow-on conference call on or about Feb 26th
  time to be confirmed

11
Consensus

• While not formalized, consensus seemed to be
  reached on the following
• There is business value in developing and
  adopting standards regarding higher level
  payment models, both business and technology
• This compliments other work that focuses on
  information and data models
• Financial industry must agree to participate
  this is the highest priority
• The OMG-MDA approach is the most suitable
  methodology for this initiative
• The business/political/social issues are
  challenging
• An OMG working group is to be formed to pursue
  this initiative.

12
Notes

• The following notes were taken during the meeting
  but may lack context for those not in attendance

13
Scope Questions

• The following issues were identified by the group
• Assurance did the payer get the things for
  which they made a payment?
• Nail down the concept of business context as
  identified in the white paper.
• Can we fully separate concerns?

14
Discussion Notes

• Consumer of this initiatives effort
• Financial institutions (FI)
• Technology providers to FIs
• New products, information
• Business Objectives
• All FIs, and their systems providers, build
  payment gateways continually with most of the
  business context created anew each time. This
  approach is costly and prone to error.
• 60 of the time spent in development of payment
  gateways chasing this information
• Adding a new value to certain payment message
  fields can take 18 mo and 1m per FI
• Rate of occurrence every day new data elements
  come into existence.
• This prevents FIs at every level from offering
  new solutions quickly, and in some cases, e.g.,
  Community banks, not at all costly opportunity
  losses
• Primary objective move payments to electronic
  means
• Inhibiters multiple business models / multiple
  technologies no agreement among FIs and their
  supplier about what data means.
• Examples Bill pay, card acceptance

15
Mission statement brainstorming notes (1)

• The mission of the Electronic Payments
  Interoperability Working Group is to enable
  greater adoption of electronic payments by
  developing a model-driven framework for
• Agreement on payment processes and
• Rapid deployment of necessary changes to payment
  protocols and interfaces.
• Rapidly adapting to changes in payment protocols
  and interfaces.
• The framework will use models of common business
  intent the federation of financial partners in
  collaborative payment processes. The framework
  will embrace protocols that have wide support
• The framework will eliminate the need to design,
  build, implement, and maintain scores of custom
  protocols and interfaces. The Working Group
  envisions accomplishing this mission by using
  formal models of business intent to drive payment
  systems.
• The framework will be widely recognized by the
  business and financial communities as a means to
  reduce cost and enable rapid realization of new
  business
• 
  (continued on next
  slide)

16
Mission statement brainstorming notes (2)

• Binding business process to model of the business
  process.
• Binding business process model to specific
  protocol.
• The framework will build standard models for
  business processes that require seamless access
  to payment systems.
• The WG will achieve its mission by publishing
  formal models of interoperability between payment
  and business systems.
• Federation A community or collection of multiple
  domains, entities, groups, and so forth that come
  together to share resources while retaining
  autonomy over those resources.
• Interaction Framework An interaction framework
  consists of a set of frameworks to support
  interaction of distributed systems independently
  of implementation details such as specific
  communication protocols and middleware systems.
• Interoperability The ability of two or more
  systems or system objects to exchange information
  in such a way as to mutually understand and use
  the information that has been exchanged.
• Federate (v) The action of federating a
  configuration of services or applications.