OFX also supports electronic enrollment, account sign-up and account activation.
Banking, loan, amortization and credit card data is available to Open Financial Exchange clients through the statement download facility. Statement download provides a way to download transaction data, statement and/or check images, and balances on an as-needed basis. Statement closing information can be made available to clients as well.
Statement download allows a customer to receive transactions, images and balances that are typically part of a regular paper statement. Clients can retrieve this information as often as they wish. Coupled with the information returned by a statement closing information request, a client can construct an "electronic statement" that contains all of the information that appears on a regular paper statement. Alternatively, an image can be retrieved which is an image of the closing statement, if the FI supports this.
Clients typically allow customers to view these transactions and guide customers through a process of updating their account registers based on the downloaded transactions. By using transaction IDs supplied by financial institutions, OFX makes it possible for clients to insure that a server downloads each transaction only once. The request also contains starting and ending dates to limit the amount of downloaded data. Clients can remember the last date they received data and use it as the starting date in the next request.
Statement download requires the client to designate an account for the download, and to indicate if the server should download transactions and/or balances. If the client wishes to download transactions, it can specify a date range that the transactions should fall within. Banking statement download options include: checking, savings, money market, credit card, and line of credit accounts. As stated above, credit card, loan statement and amortization downloads are also possible.
OFX provides a way for customers to receive closing statement information that typically appears as part of a paper statement. This information includes opening and closing dates and balances for a statement period, as well as a detailed breakdown of debits, credits, fees and interest that are usually part of a paper statement. In addition to this information, clients receive a date range for transactions that correspond to the closing statement. Clients might wish to use this date range to retrieve transactions through statement download in order to present the user with an "electronic" statement.
Additionally, closing statement images, corresponding to a paper statement copy, can be downloaded.
OFX supports a request to issue a stop payment for one or more outstanding checks. The stop request can be for a single check or for a range of checks. There must be one request for each check or range of checks the user wants to stop.
OFX supports transferring funds between two accounts at the same financial institution. Funds transfers in OFX can be immediate or scheduled. Scheduled transfers can repeat at specified intervals.
The “interbank funds transfer add request” provides a way for a clients to set up a single transfer between accounts at different financial institutions. Like intrabank funds transfers, the request designates source and destination accounts and the amount of the transfer. Also, as in the intrabank funds transfer, the FI must be able to authenticate the source account. However, interbank funds transfers differ from intrabank funds transfers in the following respects:
In all other respects, interbank funds transfers function like intrabank funds transfers. The user can schedule, modify, and cancel them. They can recur at regular intervals.
OFX enables clients to set up wire funds transfers. Wire funds transfers are similar to other types of funds transfers. Clients designate a source account that the FI can authenticate and a destination account at the same or a different institution. Clients also designate an amount and an optional date.
The FI must know the originator of the transfer. The beneficiary of the transfer might be an established customer at the same institution.
OFX implements wire funds transfers using the FedWire system, and is subject to its rules and regulations.
Banking customers must be able to obtain the current status of transactions previously sent to the server for processing. For example, once a client schedules a transfer and the transfer date has passed, the customer might wish to verify that the server made the transfer as directed. Also, OFX allows for interactions with the server through multiple clients. This means, for example, that the customer can perform some transactions from a home PC and others from an office computer, with each session seamlessly incorporating the activities performed on the other.
To accomplish these actions, the client uses a synchronization scheme to insure that it has an accurate copy of the server data that is relevant to the client application.
Banking requires synchronization in the following areas: Stop Check, IntraBank Transfers, InterBank Transfers, Wire Transfers, and Banking Notifications (e-mails).
|Bill Payment Services|
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 payee", 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.
OFX 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.
Clients can identify a payee in one of three ways:
Identifiers Used in Payment Transactions
Payment transactions use four types of 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>) is assigned by the server to a payment "object", which can either be a payment or a recurring payment model. The Server Identifier is used to identify a payment in a request to modify or cancel it. The Server Identifier is valid for the life span of the payment within the payment system.
A payment system can assign the Payee Identifier (<PAYEEID>) to a standard payee. There is no requirement that all or any payees are assigned a payee ID. The usage of this identifier will vary by payment system.
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. Systems employ a Payee List Identifier to insure that in systems where payees will not always have a Payee Identifier, there is another identifier that can be used to reference every payee. This ensures that a client can correctly link payments to their payees.
Payment functions allow a client a Payment Request to pay a bill on a specified date. The Payment Request identifies the payee and the amount to pay.
A Payment Request is used to schedule an electronic payment. The server responds with a Payment Response. Separate transactions are provided for modifying and canceling a Payment Request.
The client formulates a <PMTRQ> that includes the payee, the date, and the amount of the payment. 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. The server responds to the <PMTRQ> with a payment response (<PMTRS>).
Recurring payments are used when a payment is to be made repeatedly at some known interval. Setting up a recurring payment is similar to creating an individual payment, but with additional information about the frequency and number of payments. After a recurring payment is created, the server will generate payment transactions when there are a specified number of days remaining until the next projected payment is due (usually 30 days). The client will be made aware of any generated payment transactions through the synchronization process.
|Bill Presentment Services|
Bill Presentment Advantages
As more and more people get connected to the Internet, the number of transactions over the Internet is increasing rapidly. Billers need to start planning and implementing new billing systems now to take advantage of the new opportunities. Here are some of the benefits you can expect from implementing interactive Bill Presentment into your billing systems.
Build Stronger Relationships with Customers
Utilizing interactive bill presentment gives you the ability to provide new services for customers and communicate with them in new ways.
By implementing an interactive Bill Presentment system for your customers, you can reduce operational costs by decreasing paper, printing and postage expenses.
Consistent and Timely Delivery
Delivery of Bill Presentment to customers is delivered in a more effective means. You can improve customer payment accuracy by integrating online payment with your billing programs which will in turn, give your customers a sense of continuity and build trust in online billing systems.
Enhance Company Image
Delivering innovative services that benefit your customers strengthens your company image as a champion for consumers. By working with new technologies, your company builds a reputation as an industry leader.
Bill Presentment Model
This section summarizes the process of receiving bills electronically, starting with the steps required to find a bill publisher and set up Bill Presentment service.
To receive bills electronically, the client:
Servers and Message Sets
During the billing process, the client typically communicates with two Open Financial Exchange servers:
Although it is possible for a single server to perform both of the functions listed above, it is more likely that independent directory servers will provide clients with a single source for finding billers.
Customer Sign Up
Once the customer has located a biller and its associated bill publisher, the customer must enroll with the bill publisher for Bill Presentment service and activate accounts for one or more billers at the bill publisher. Bill Presentment uses the standard OFX Signup Message Set.
Typically, the client periodically requests a list of bills from the bill publisher. The bill publisher responds with a list of bills, each of which contains summary data such as the due date and amount due. For each bill, the bill publisher might also return a URL to a Web site that contains an HTML-rendered version of the bill. Depending on the client’s request, the server might also return structured bill detail for a given bill.
Types of Response Information
The response consists of five types of information:
Many FIs distinguish between activity and positions in cash, margin, and short accounts, with some FIs having many other types of "sub-accounts". OFX defines four standard types of sub-accounts: Cash, Margin. Short, Other. Position, Transaction, and Open Order records identify the sub-account.
Units, Precision, and Signs
The units for security units and unit price are those commonly used on brokerage statements, and differ for each type of security.
OFX does not specify the precision of fields since the precision is client-dependent. Clients and servers should send as much precision as they have.
Quantities and total values should be signed from the perspective of the user. In a stock buy, the total value is negative, the unit price is always positive, and the number of units is positive.
Bank & Investment Transactions
Many FIs provide investment accounts that allow users to write checks and perform other traditional banking transactions, as well as investment transactions. OFX requires FIs to indicate in the download whether check writing privileges exist for a given account.
FIs need to use the correct transactions record, bank or investment, for each real-world transaction. Use the following guidelines:
Checks, electronic funds transfers, and ATM transactions associated with CMA or money markets sweep accounts are always represented with a bank transactions record.
Investment actions that involve securities (buy, sell, stock, split, reinvest, etc.) are always represented with an investment record. Actions that are cash-only but are directly associated with a security are also investment actions (for example, dividends).
Other cash-only actions require careful analysis by the FI. Those that impact investment performance analysis should be sent using the appropriate investment action (investment income-miscellaneous, investment expense). Those that are completely unrelated to investment should be sent as a bank record.
Money Market Funds
Money market funds can be handled in one of three different ways depending on how the fund is modeled at the financial institution.
In OFX 2.0 and later, 401(k) information can be downloaded with investment transaction detail. Also 401(k) account summary information such as contributions, matches, vesting amounts, year to date amounts, etc. can be downloaded.
Investment Statement Download
Investment statement download allows a customer to receive transactions, positions, open orders and balances that are typically part of a regular paper statement. Clients can retrieve statement data on a daily basis if they wish.
Clients usually allow customers to view investment transactions and guide customers through a process of updating their account registers based on the downloaded transactions. By using transactions Ids supplied by FIs, OFX makes it possible for clients to insure that each transaction is downloaded only once. The request also contains starting and ending dates to limit the amount of downloaded data. Clients can remember the last date they receive a download, and use that date as the starting date in the next request.
Investment statement download requires the client to designate an account for the download, and to indicate what type of data should be downloaded. If the client wishes to download transactions, it can specify a date range that the transactions fall within. The server returns transactions that match the date range, if one is specified. If a date range is not specified, the server returns all available transactions for the account.
|About OFX | Developer Information | Press Room | Home|
|Download Spec | View Schema/DTD | Site Map | OFX.NET|
|For more information or questions about OFX, please
email us at email@example.com
©2007 Open Financial Exchange, All Rights Reserved