DOC

OpenExchange Message Set Specification

By Jon Kelley,2014-05-05 09:00
10 views 0
OpenExchange Message Set Specification

    Open Financial Exchange

    Specification 1.0.2

    May 30, 1997

    ? 1997 CheckFree Corp., Intuit Inc., Microsoft Corp. All rights reserved

    Chapters 12 & 13

Open Financial Exchange Specification 1.0.2 5/30/97

198

Contents

    12. PAYMENTS ..................................................................................................................................201

    12.1 CONSUMER AND BUSINESS PAYMENTS .........................................................................................201 12.2 THE PAYEE MODEL .....................................................................................................................201 12.2.1 Payee Identifiers ..................................................................................................................201

    12.2.2 Payee Lists ..........................................................................................................................202

    12.2.3 Standard Payee Lists ...........................................................................................................203

    12.2.4 Summary Identifying Payees ............................................................................................203 12.3 IDENTIFIERS USED IN PAYMENT TRANSACTIONS ...........................................................................204 12.4 THE PAYMENT LIFE CYCLE ..........................................................................................................205 12.4.1 Payment Creation ................................................................................................................205

    12.4.2 Payment Modification .........................................................................................................205

    12.4.3 Payment Status Inquiry .......................................................................................................205

    12.4.4 Payment Cancellation..........................................................................................................206

    12.4.5 Delayed Payee Matching .....................................................................................................206

    12.5 COMMON PAYMENTS AGGREGATES .............................................................................................206 12.5.1 Payments Account Information ..............................................................206 12.5.2 Payment Information .....................................................................................207 12.6 PAYMENTS FUNCTIONS ................................................................................................................211 12.6.1 Payment Creation ................................................................................................................212

    12.6.2 Payment Modification .........................................................................................................214

    12.6.3 Payment Cancellation..........................................................................................................216

    12.6.4 Payment Status Inquiry .......................................................................................................217

    12.7 RECURRING PAYMENTS ...............................................................................................................218 12.7.1 Creating a Recurring Payment.............................................................................................219

    12.7.2 Recurring Payment Modification .........................................................................................222

    12.7.3 Recurring Payment Cancellation .........................................................................................225

    12.8 PAYMENT MAIL ..........................................................................................................................226 12.8.1 Payment Mail Request and Response ...................................................................................226

    12.8.2 Payment Mail Synchronization............................................................................................227

    12.9 PAYEE LISTS ...............................................................................................................................228

    12.9.1 Adding a Payee to the Payee List .........................................................................................229

    12.9.2 Payee Modification ..............................................................................................................232

    12.9.3 Payee Deletion ....................................................................................................................234

    12.9.4 Payee List Synchronization .................................................................................................235

    12.10 DATA SYNCHRONIZATION FOR PAYMENTS ..................................................................................236 12.10.1 Payment Synchronization ..................................................................................................236

    12.10.2 Recurring Payment Synchronization..................................................................................237 12.10.3 Discussion .........................................................................................................................238

    12.11 MESSAGE SETS AND PROFILE .....................................................................................................239 12.11.1 Bill Pay Message Sets and Messages .................................................................................240

    12.11.2 Bill Pay Message Set Profile ..........................................................242 12.12 EXAMPLES ................................................................................................................................243

    12.12.1 Scheduling a Payment .......................................................................................................243

    12.12.2 Modifying a Payment ........................................................................................................247

    12.12.3 Canceling a Payment .........................................................................................................251

    12.12.4 Updating Payment Status ..................................................................................................252

    12.12.5 Scheduling a Recurring Payment .......................................................................................253

    12.12.6 Modifying a Recurring Payment ........................................................................................255

    12.12.7 Canceling a Recurring Payment ........................................................................................257

     Open Financial Exchange Specification 1.0.2 5/30/97

    199

12.12.8 Adding a Payee to the Payee List .......................................................................................258

    12.12.9 Synchronizing Scheduled Payments ..................................................................................259 13. INVESTMENTS ............................................................................................................................263

     TYPES OF RESPONSE INFORMATION ..............................................................................................26413.1

    13.2 SUB-ACCOUNTS ..........................................................................................................................264 13.3 UNITS, PRECISION, AND SIGNS .....................................................................................................264 13.3.1 Units ...................................................................................................................................264

    13.3.2 Precision .............................................................................................................................265

    13.3.3 Signs ...................................................................................................................................265

    13.4 BANK AND INVESTMENT TRANSACTIONS ......................................................................................265 13.5 MONEY MARKET FUNDS..............................................................................................................265 13.5.1 Separate Account at the Financial Institution ......................................................................266 13.5.2 Sweep Account Within an Investment Account ...................................................................266 13.5.3 Position Within an Investment Account ..............................................................................266 13.6 INVESTMENT ACCOUNTS .............................................................................................................266 13.6.1 Specifying the Investment Account .....................................................266 13.6.2 Investment Account Information ..........................................................267 13.6.3 Brokerage, Mutual Fund, and 401K Accounts .....................................................................268 13.7 INVESTMENT MESSAGE SETS AND PROFILE ...................................................................................268 13.7.1 Investment Statement Download .........................................................................................268

    13.7.2 Security Information ...........................................................................................................270

    13.8 INVESTMENT SECURITIES .............................................................................................................271 13.8.1 Security Identification .........................................................................................271

    13.8.2 Security List Request ...........................................................................................................271

    13.8.3 Security List Response ........................................................................................................272

    13.8.4 Security List ...................................................................................................273

    13.8.5 Securities Information .........................................................................................................273

    13.9 INVESTMENT STATEMENT DOWNLOAD .........................................................................................279 13.9.1 Investment Statement Request .............................................................................................279

    13.9.2 Investment Statement Response...........................................................................................281

    13.10 INVESTMENT E-MAIL ................................................................................................................295 13.10.1 Investment E-Mail Request and Response .........................................................................296 13.10.2 Investment E-Mail Synchronization ..................................................................................297

    13.11 COMPLETE EXAMPLE .................................................................................................................298

     Open Financial Exchange Specification 1.0.2 5/30/97

    200

12. Payments

    This section describes the Payments portion of Open Financial Exchange. Open Financial Exchange Payments consists of a set of functions for scheduling and maintaining payment transactions, and for synchronizing with the server to obtain an accurate status of all recent and scheduled transactions. Clients use payment requests to schedule payments and to modify or delete payments if necessary. Open Financial Exchange also supports business payments, as described in section 12.1.

    The recurring payments function allows the client to schedule automatic generation of a series of recurring payments by means of a single request. As with individual payments, the client can modify or delete these requests.

    The payments function incorporates the synchronization features of Open Financial Exchange, allowing multiple client applications to synchronize with the server to obtain the current status of all payment transactions known to the server.

    In many international environments, payments are performed using intrabank funds transfers. Open Financial Exchange Payments supports this by allowing a payee to be designated as a destination bank account. Servers can implement these messages as transfers where appropriate.

    12.1 Consumer and Business Payments

    Open Financial Exchange Payments is designed to support both consumer and business payments. Businesses have additional requirements for payments. In particular, there is a need to include itemized instructions that specify how a payment should be disbursed across multiple invoices and/or line items. Open Financial Exchange supports this requirement through the inclusion of the aggregate within payment requests. The Payment Modification Request also supports changes to data.

    12.2 The Payee Model

    The payee model in Open Financial Exchange is designed to provide support for both ―pay-some‖ and

    ―pay-any‖ payment systems. ―Pay-some‖ systems are those that restrict users to only make payments to payees that appear on an approved list. Such payees are often referred to as ―standard payees,‖ or ―standard merchants.‖ These are generally larger corporations that receive high volumes of payments, such as telephone companies or power utilities. In contrast, pay-any‖ systems allow payments to any

    payee for which the user provides accurate billing information. These systems often also include a list of standard payees.

    12.2.1 Payee Identifiers

    Open Financial Exchange is designed to be flexible in the requirements for payee identifiers. It supports systems where all, some, or no payees are assigned a payee ID. In addition, it enables the server to assign an ID to a payee that was previously being paid by billing address.

     Open Financial Exchange Specification 1.0.2 5/30/97

    201

    You must implement the scope of payee such that the ID is at least global across the user’s set of payments-enabled accounts with the payments provider. For example, if the user has both a checking and a money market account enabled for payments with the payments provider, then a payee ID obtained for a payment made from one of these accounts should identify the same payee if used for a payment drawn on the other account. This simplifies client support for allowing a user to choose from which account to make a payment.

    Open Financial Exchange requires payee identifiers to have a one-to-one relationship with the corresponding PAYEE information. In other words, different payee IDs must also differ in their corresponding payee billing description or payee name (NAME). Similarly, a payee ID must be independent of a user’s account number with the payee. However, the payment system is free to use the user’s account number in combination with the payee ID to determine the routing of a payment. These rules are intended to simplify the payee model for the user, insuring that different payee IDs will have discernibly different descriptions associated with them. They also insure that the user will not be required to maintain multiple payee entries for a payee with which the user holds multiple accounts. Open Financial Exchange includes a tag for indicating the scope of a payee ID returned from the server. This allows clients to adapt by expanding or restricting their functionality depending on the scope of payee IDs it encounters.

    A payee list for each user, maintained on the server, allows the server to manage the identifiers assigned to a user’s payees. This functionality is described in the next section.

    12.2.2 Payee Lists

    Open Financial Exchange specifies that a server-hosted payee list is maintained for each payments user. This list contains the payees that a user has paid through the payment system, or has set up to pay. Updates to this list are available through the synchronization mechanism. This insures that multiple clients have access to the full list of payees the user has configured. It is only necessary to enter each payee once.

    Some payment systems require a first time setup before using a payee. This can occur externally to the client and server software, for example by filling out a paper form or telephoning the bank. In this case, payee list synchronization provides a way for the payee to become accessible to the client software when the FI completes the setup.

    The list can contain payees with or without payee IDs. An important function of the payee list is to communicate payee changes from the server to the client. This includes changes in processing date parameters and conversion of a payee to a standard payee.

    Once added to the list, the payment system makes payments by the payee list ID. This makes it clear to a client when the user is adding to a payee list, and when he or she modifies an existing payee on the list. Although the messages make it clear whether a client is trying to add a new payee, a careful server will check for exact matches on payee adds and not create new payee list entries unnecessarily. ―Pay-any‖ systems can perform background processing that matches billing addresses with standard payees. When this occurs the server can update the relevant payee lists, and update the clients when they synchronize with the modified list data.

     Open Financial Exchange Specification 1.0.2 5/30/97

    202

    Each payee entry in the list can also include a list of the user’s accounts with that payee. This further reduces the data entry required by a user to make a payment, and facilitates the implementation of lightweight clients.

    12.2.3 Standard Payee Lists

    Many payment systems maintain a list of payees that receive payments from a large number of users. Payments to these payees are usually consolidated into a few electronic funds transfers or are mailed in large batches to the payee. Payees that receive this special processing are generally referred to as standard payees. In a ―pay-some‖ system, all the approved payees can be considered to be standard payees. When a user pays a standard payee, there might be different processing lead-times used to calculate the payment and/or processing date of a payment.

    When a payment system includes a standard payee list, it might be desirable to present the list to the user, who can then select payees he or she wants to pay. Unfortunately, it is cumbersome to provide this functionality in the client software due to the potential size of this list, which makes it problematic to keep updated and to present to the user. While the list can contain thousands of payee entries, a user will typically need less than ten or twenty entries from the list. It can also be difficult for a user to choose the correct payee entry when the list contains a number of similarly named payees.

    Therefore, Open Financial Exchange does not provide a mechanism for delivering these lists to the client. However, there are several ways that an external presentation of such a list can be integrated into the client or server. For example, a payment provider’s Web site could present a search engine that assists the

    user to locate the correct payee. Once identified, the payees can either be imported into the client, or inserted into the user’s payee list on the server. In the latter case, synchronizing the payee list will make the newly added payees visible to the client.

    12.2.4 Summary Identifying Payees

    Clients can identify a payee in one of four ways:

    ; Name & address, by means of should be done only once for each payee. Thereafter,

    clients should use the assigned or . If the clients sends both

     and , it is an implicit payee modification request. If a client sends

    just , it is an implicit payee add request. Duplicate payee list entries can occur if

    clients are not careful to send the payee list ID in subsequent requests.

    ; Destination bank account should be done only once for each payee.

    Thereafter, clients should use the assigned or , as with name and

    address payees. The aggregate is required to provide name and address information as

    a backup to account transfers.

    ; Payee list ID after a payee has been added to the list, for payees that have not

    been assigned a standard payee ID .

    ; Standard payee ID for any payee that has been assigned a standard payee ID.

    This could happen before a closed system makes any payments, or anytime after the server has

    notified the client that a payee has a standard payee ID.

     Open Financial Exchange Specification 1.0.2 5/30/97

    203

12.3 Identifiers Used in Payment Transactions

    Payment transactions use four types of identifiers. It is important to understand the purpose, scope, and life span of these identifiers.

    The client-to-request messages assign the Transaction Universal Identifier (TRNUID). Its purpose is to allow the client to easily match responses from the server to their corresponding requests. A given transaction ID is used only for a client request and the corresponding server response. The Server Identifier (SRVRTID or RECSRVRTID) is assigned by the server to a payment ―object,‖ which can either be a payment or a recurring payment model (in which case it is named RECSRVRTID). Both the client and server use the ID thereafter to refer to the payment or model in any transactions that operate on them. For example, the SRVRTID is used to identify a payment in a request to modify or cancel it. The SRVRTID is valid for the life span of the payment within the payment system. Similarly the RECSRVRTID is valid as long as the associated model exists, that is until the model generates all payments, or the model is canceled. Once a server processes a payment or a model generates all its required payments, the associated SRVRTID (or RECSRVRTID) is no longer known to the server. Note that the payment system might continue to maintain knowledge of a payment SRVRTID or model RECSRVRTID for some specified period after it completes processing. This allows clients to access the ―completed‖ status of these operations.

    A payment system can assign the Payee Identifier (PAYEEID) to a payee. There is no requirement that all or any payees are assigned a PAYEEID. The usage of this identifier will vary by payment system. For example, in ―pay-some‖ systems usually every payee has a payee ID with a scope that is known globally, while in ―pay-any‖ systems there might only be PAYEEIDs assigned to standard payees. When a payee has an assigned PAYEEID, the life span of the ID will depend on its scope. If the scope is global, such as for payees in some ―pay-some‖ systems or those with standard payees, then the PAYEEID is expected to

    be valid as long as that payee is identifiable by ID. If the payee ID is user-specific in scope, then the PAYEEID is valid as long as the payee appears in the user’s server-hosted payee list.

    The Payee List Identifier (PAYEELSTID) is assigned by the server to each entry in a user’s server-hosted

    payee list. The need for this identifier is to support the variety of payee models employed in various payment systems. As discussed above, some payment systems assign a payee identifier (PAYEEID) to every payee (this is particularly the case with pay-some systems); others assign PAYEEIDs only to standard payees. There are also systems that cannot map a payee billing address to a PAYEEID in real time. Also, there are systems that can convert a payee from a standard payee with an assigned PAYEEID to one that is identified only by billing address. Therefore, systems employ the PAYEELSTID to insure that, in systems where payees will not always have a PAYEEID, there is another identifier that can be used to reference every payee. This insures that a client can correctly link payments to their payees. The PAYEELSTID must be valid as long as the user’s payee list includes the payee it identifies, even if the server subsequently assigns a PAYEEID to the payee.

     Open Financial Exchange Specification 1.0.2 5/30/97

    204

12.4 The Payment Life Cycle

    12.4.1 Payment Creation

    The client formulates a PMTRQ that includes the payee, the date, and the amount of the payment. If supported by the user’s payment system, the billing address can specify the payee.

    The server will look up the payee in the user’s payee list. If it is not already in the table, the server will add it and issue a payee list identifier (PAYEELSTID). This form of payment request performs an implicit Payee Request (PAYEERQ), which is equivalent to explicitly adding the payee (by means of a PAYEERQ), prior to issuing the PMTRQ. It has the advantage of being atomic. If the payment request fails, the payee is not added to the user’s payee list. Conversely the payment request will fail if the payee information is invalid.

    The server responds to the PMTRQ with a Payment Response (PMTRS). Some servers will not be able to immediately return a payee ID at this point, or might not issue payee IDs for all payees. Therefore the PAYEELSTID contained in the response functions as the linkage between the payee and the payment. Payment systems use the SRVRTID returned in the PMTRS to identify the payment for the length of its instantiation on the payment system.

    12.4.2 Payment Modification

    Between the time the client schedules a payment and the time the server processes the payment, the client can request changes to the parameters of that payment. For example, the amount or date of the payment can be modified. The system uses the Payment Modification Request (PMTMODRQ) for this purpose, where the SRVRTID from the PMTRS identifies the targeted payment. The user request must specify the full contents of the payment request, including both modified and unmodified data.

    Full-featured servers will use PMTMODRS messages, conveyed to the client during synchronization (PMTSYNCRS), to inform the client about changes in the state of the client that occur due to server processing. This would include reporting the date the server actually processed a payment, or it failed due to insufficient funds. Servers that are unable to generate PMTMODRS responses for this purpose must support the PMTINQRQ message described below.

    12.4.3 Payment Status Inquiry

    As a scheduled payment progresses through its ―life-cycle‖ on the server, the processing status changes

    accordingly from ―scheduled to be processed‖ to ―was processed‖ or ―failed processing.‖ A processing date is associated with these states. The preferred method for providing updated processing status to a client is by use of server-generated Payment Modification messages (PMTMODRS), as discussed above. However it is possible that less full-featured servers might have difficulty in implementing this form of notification. In this case, Open Financial Exchange requires such servers to implement the Payment Status Inquiry message (PMTINQRQ), which provides an interface for the client to explicitly request the processing status of individual payments.

     Open Financial Exchange Specification 1.0.2 5/30/97

    205

12.4.4 Payment Cancellation

    In the interval between successful processing of a PMTRQ and the actual processing of the payment, the client can cancel the payment by issuing a Payment Cancellation Request (PMTCANCRQ). The SRVRTID value returned in PMTRS identifies the payment.

    When a payment system cancels a payment, servers can generate a PMTCANCRS. This might occur if the user requests payment cancellation by way of a telephone call to customer support or through an e-mail message. The client will receive this response when performing a synchronization (PMTSYNCRQ/PMTSYNCRS).

    12.4.5 Delayed Payee Matching

    Payment systems that allow payment by payee billing address often perform a matching operation to determine if the payee is a standard payee. If this matching occurs in the processing of a PMTRQ, and the server recognizes the payee as a standard one, then the server returns the payee ID and payment parameters in the EXTDPAYEE aggregate of the PMTRS. However some payment systems will not be able to perform ―payee matching‖ at this point in processing. In this case, the server sends updated payee information to the client by using PAYEESYNRQ to synchronize the payee list. The client can link payee information in the PAYEETRNRS messages to payments with matching PAYEELSTID identifiers. 12.5 Common Payments Aggregates

    This section documents several aggregates used throughout the Payments portion of the Open Financial Exchange specification.

    12.5.1 Payments Account Information

    Open Financial Exchange uses the payments account information aggregate to download account information from an FI. It includes account number specification in BANKACCTFROM as well as the status of the service. In Open Financial Exchange, Banking and Payments share the BANKACCTFROM aggregate to identify a specific account. For more information, see section 11.3.1.

     Payments-account-information aggregate

     KACCTFROM> Bank-account-from aggregate

    

     Status of the account

    AVAIL = Available, but not yet requested

    PEND = Requested, but not yet available

    ACTIVE = In use

    

     Open Financial Exchange Specification 1.0.2 5/30/97

    206

Report this document

For any questions or suggestions please email
cust-service@docsford.com