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.

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 <EXTDPMT>
aggregate within payment requests. The Payment Modification Request
<PMTMODRQ> also supports changes to <EXTDPMT> data.

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.

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.

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.

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.

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.

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.

Name & address, by means of <PAYEE>
- should be done only once for each payee. Thereafter, clients
should use the assigned <PAYEELSTID> or <PAYEEID>.
If the clients sends both <PAYEE> and <PAYEELSTID>,
it is an implicit payee modification request. If a client sends
just <PAYEE>, 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 <BANKACCTTO> -
should be done only once for each payee. Thereafter, clients should
use the assigned <PAYEELSTID> or <PAYEEID>, as with
name and address payees. The <PAYEE> aggregate is required
to provide name and address information as a backup to account
transfers.

Payee list ID <PAYEELSTID> - after a payee
has been added to the list, for payees that have not been assigned
a standard payee ID <PAYEEID>.

Standard payee ID <PAYEEID> - 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.

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 merchants, 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.

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.

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.

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.

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).

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.

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.

The Payment Information aggregate is used to specify
detailed payment information. It is used for both single payments
and recurring payments. Clients must send the <PAYEELSTID>
and <PAYEEID> if known. Clients send a <PAYEE> aggregate
if this is an implicit payee add or modify. See section 12.2.4
on identifying payees, above. The <EXTDPMT> aggregate (see
section 12.5.2.2) allows the inclusion of disbursement instructions
to be printed with the payment. This aggregate is optional.

Tag

Description

<PMTINFO>

<BANKACCTFROM>

Account-from aggregate, see section 11.3.1

</BANKACCTFROM>

<TRNAMT>

Payment amount

<PAYEEID>

Server payee identifier (required if assigned). Either <PAYEEID> or <PAYEE> can be sent, but not both

<PAYEE>

Complete payee billing information, see section 12.5.2.1 Either <PAYEEID> or <PAYEE> can be sent, but not both

</PAYEE>

<PAYEELSTID>

Payee list ID (required if assigned)

<BANKACCTTO>

Destination account information, for systems that pay by transfers (<PAYEE> also required)

</BANKACCTTO>

<EXTDPMT>

Extended Payment aggregate, see section 12.5.2.2, optional

</EXTDPMT>

<PAYACCT>

User account number with the payee

<DTDUE>

Payment due date

<MEMO>

Memo from user to payee

<BILLREFINFO>

Biller-supplied reference information when paying a bill, if available,
A-80

The Extended Payment aggregate provides the payee
with information for applying a payment across multiple invoices.
It is structured to allow for electronic processing of the invoice
date, and allows multiple invoices, as well as multiple line items
per invoice, to be specified.

In this case, EXTDPMT can specify a block of free
text to be transmitted with the payment, by using the EXTDPMTDSC
instead of the EXTDPMTINV element.

All amount fields (INVAMT, DSCAMT, ADJAMT, LITMAMT)
can be negative.

Tag

Description

<EXTDPMT>

Extended Payment aggregate

<EXTDPMTDSC>

Free text to communicate with the payment (either EXTDPMTDSC or EXTDPMTINV)

<EXTDPMTINV>

Invoices (either EXTDPMTDSC or EXTDPMTINV)

<INVOICE>

Start tag for the invoice aggregate. There can be one or more invoices per payment request.

<INVNO>

Invoice number associated with the payment.

<INVTOTALAMT>

This value represents the total invoice amount. Left-justified, blank-filled Money format includes a decimal point.

<INVPAIDAMT>

This value represents the amount of the invoice being paid. Left-justified, blank-filled Money format includes a decimal point.

The Extended Payee aggregate communicates a payee
identifier to the client. It also contains the processing day
parameters for a payee. It can be sent to the client for any payee
whose processing day parameters are different from the processor's
default values, even for payees with no IDs.

Tag

Description

<EXTDPAYEE>

Extended-payee aggregate

<PAYEEID>

Server-assigned payee ID

<IDSCOPE>

Scope of the payee ID; one of {GLOBAL, USER }, where
GLOBAL = payee ID valid across the entire payment system
USER = payee ID valid with all FI accounts set up for the user's
payments account

Payments functions allow a client to create a Payment
Request to pay a bill on a specified date. The Payment Request
identifies the payee and the amount to pay.

Client Sends

Server Responds

Account information

Payment date

Amount

Payee address, list ID, transfer acct, or standard ID

Payment status

Check number

Server-assigned ID

From the time the client issues a Payment Request until it is
paid, the client can modify the transaction through the Payment
Modification Request, <PMTMODRQ>; see section 12.4.2. This
request allows payment parameters such as the payment date and
payment amount to be changed.

Client Sends

Server Responds

Account information

Server-assigned ID

Information to change:

Payment date,

Amount,...

Acknowledgment or Error

The client can cancel a Payment Request with a Payment Cancellation
Request, <PMTCANCRQ>; see section 12.4.4.

The server sends a Payment Response in response to
a Payment Request. The processing status code for a new payment
is normally WILLPROCESSON, but in the case of synchronization
it can return other status codes.

Tag

Description

<PMTRS>

Payment-response aggregate

<SRVRTID>

ID assigned by the server to the payment being created

<PAYEELSTID>

Server-assigned payee list record ID for this payee

<CURDEF>

Default currency for the Recurring Payment Response

<PMTINFO>

Payment Information aggregate, see section 12.5.2

</PMTINFO>

<EXTDPAYEE>

Standard payee information if payee is a standard payee, or payee has non-default processing day parameters; see section 12.5.2.3

Once the server has assigned a payee identifier to
the payee, it includes the <EXTDPAYEE> in any <PMTRS>
for that transaction. If the <EXTDPAYEE> aggregate is present
in the Payment Response (<PMTRS>), the client records the
standard payee information for use in future payments to the same
payee.

When a payment is made using the <PAYEE> aggregate,
and no <PAYEELSTID> is present, the payee is implicitly
added to the payee list. This is therefore equivalent to first
transmitting a <PAYEERQ> for the payee. For payment systems
that can immediately return payee IDs, it is preferable to use
the single <PMTRQ> message to both add the payee and create
the payment. If either operation fails, the server will not complete
the other. If <PAYEELSTID> and <PAYEE> are both included,
it is equivalent to sending a <PAYEEMODRQ> first.

The <PMTRS> response will include the <EXTDPAYEE>
aggregate if the processor has assigned a payee ID to the payee
specified in the payment. It will also appear in the response
when the payee has no assigned ID, but has processing day parameters
that different from the processor's defaults for these values.
This might occur, for instance, if the processor notes that the
zip code of the payee indicates a certain proximity to the payer,
and therefore wishes to offer a shorter <DAYSTOPAY> value.

The Payment Modification Request allows a client
to modify a previously scheduled payment. When modifying a payment,
the client specifies only the tags within the <PMTRQ> aggregate
that it wants to modify. The ability to modify some tag values
might not be supported by all servers.

Servers can initiate <PMTMODRS> messages to
communicate changes in the processing status of a payment as it
moves through the payment system. This mechanism allows a client
to capture the updated status of payments every time it synchronizes.

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
payments 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. Chapters 10
and 11 provide additional details on models and recurring transactions,
and defines the recurring transaction aggregates.

The table below lists the functional elements for
creating a recurring payment:

Client Sends

Server Responds

Account information

Payment frequency

Number of payments

Payment date

Amount

Payee address, list ID or payee ID

Standard payee information

Server-assigned ID

The table below lists the functional elements for modifying a
recurring payment:

Client Sends

Server Responds

Account information

Server-assigned ID

Information to change:

Payment frequency,

Number of payments,

Payment date,

Amount,...

Acknowledgment or Error

The table below lists the functional elements for canceling a
recurring payment:

Use a Recurring Payment Request to set up a recurring
electronic payment. The user can specify the frequency and duration
of the payments using the Recurring Instructions aggregate <RECURRINST>.
The <PMTINFO> aggregate (see section 12.5.2) specifies the
payment information.

The client sends a Recurring Payment Modification
Request to request modifications to a recurring payment previously
created with a Recurring Payment Request. The payment frequency
(<RECURRINST>), the payment parameters (<PMTINFO>),
or both, can be changed.

Users can correspond by way of e-mail to resolve
problems or ask questions about their payments accounts. This
function makes use of the general Open Financial Exchange e-mail
facility, which is described in Chapter 9.

The <PMTMAILRQ> allows a client to issue an
e-mail to the payments processor. If the message refers to a specific
payment, then both <SRVRTID> and <PMTINFO> are required
to identify the payment to the processor.

Tag

Description

<PMTMAILRQ>

Payment e-mail-request aggregate

<MAIL>

General e-mail aggregate

<SRVRTID>

Transaction ID of the payment that is the subject of the correspondence

Payments-system servers store lists of payees set
up for payment by each user. Some systems require this before
the user can issue a payment to a payee. In other payment systems,
this feature enables the sharing of payee entry among multiple
clients, and simplifies server payee maintenance.

A server-assigned payee list-entry ID identifies
entries in the payee list. The following set of messages allows
clients to obtain this list of payees. Users can add, modify,
and delete individual entries in the list. The request for the
list is synchronized, so that multiple clients can use the list.

Creating a payee:

Client Sends

Server Responds

Server-assigned payee identifier, or payee billing address

User's account number with the payee

Payee address

Standard payee information

Modifying a payee:

Client Sends

Server Responds

Server-assigned payee identifier

User's account number with the payee

Information to change:

payee name

address

city

state

postal code

phone number

new payee account #

Extended payee information if payee is a standard payee or has non-default processing lead times

The user can use the Payee Request to add a payee
to the server payee list. The server responds with a Payee Response,
which can contain a complete billing address for the payee, or
if the payee is a standard payee, the lead time and payee name
values.

The <PAYEERQ> requests the addition of a payee
entry to the server's payee list. Note that the user can use a
<PMTRQ> to simultaneously set up a payee. Open Financial
Exchange does not require the client to send a <PAYEERQ>
before making an initial <PMTRQ> to a payee.

Tag

Description

<PAYEERQ>

Payee-request aggregate

<PAYEEID>

Server-assigned payee identifier. Either <PAYEEID> or <PAYEE> but not both may be sent.

<PAYEE>

Complete payee billing information, see section 12.5.2.1. Either <PAYEEID> or <PAYEE> but not both may be sent

</PAYEE>

<BANKACCTTO>

For countries that pay using transfers, the destination bank account (<PAYEE> required)

The server sends the Payee Response in response to
a Payee Request. It contains the full billing information for
the payee if it is not a standard payee. Otherwise, it contains
the standard payee information, including lead time and payee
name. If the server identifies the payee as having an assigned
payee ID, then the server will include the EXTDPAYEE aggregate
in the response.

If the response indicates that the payee does not
have an assigned payee ID, the client should specify the full
billing address (PAYEE) information in subsequent payment requests
(PMTRQ) to the payee.

If the response indicates that the payee does have
a payee ID, then the client should use the payee ID for making
payments to that payee.

The server returns a Payee Modification Response
in reply to a Payee Modification Request.

When a server-initiated change occurs to the extended
payee information for a payee (for example a change in the payee's
lead time), the server can include this information in the <EXTDPAYEE>
of the response.

If a server-initiated response indicates either that
a payee now has a payee ID, or no longer has one, then the client
should use the appropriate form of designating the payee in any
future payment requests (PMTRQ) to that payee.

Tag

Description

<PAYEEMODRS>

Modification-response aggregate

<PAYEELSTID>

Server-assigned record ID for this payee record

<PAYEEID>

Server payee identifier

<PAYEE>

Payee information that was modified

</PAYEE>

<BANKACCTTO>

Destination account for countries that pay bills using transfers (<PAYEE> required as well)

This set of messages allows clients to obtain a list
of payees stored on the server that it has configured for use
in payments. In a "pay some" system, users are sometimes
required to explicitly configure the payees to whom the system
will make payments. This can be done by means of a telephone call
to the payments provider or through some other interface. The
client can then use this message set to obtain the user's list
of configured payees. In other systems, the payments provider
can elect to store a list of all payees that the user has paid.
This is a convenience to the client. It allows payees set up on
one client to be accessible from a user's other clients. The support
of this message set is optional, but can be required by "pay
some" providers that rely on this functionality.

Users of Open Financial Exchange Payments need to
be able to obtain the current status of transactions previously
sent to the server for processing. For example, once the user
schedules a payment and the payment date has passed, the user
might want to verify that the server made the payment as directed.
Additionally, Open Financial Exchange allows for interactions
with the server through multiple clients. This means, for example,
that the user can perform some transactions from a home PC and
others from an office computer with each session incorporating
the activities performed on the other.

In order to accomplish these tasks, 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.
The intent of this scheme is to address three scenarios in which
the client might lose synchronization with the server:

A transaction has changed its state based on
processing actions on the server. For example, a scheduled payment
has passed its due date and has been paid or rejected.

Transactions relevant to the client's application
state have been added, deleted, or modified by a second client.
For example, a user might enter or change transactions from more
than one PC or application.

A communications session between the client and
server was interrupted or completed abnormally. As a result the
client does not have responses from the server indicating that
all the transactions were received and processed.

This section describes specific synchronization processing
for the Open Financial Exchange Payments functions. Chapter 6
provides a more extensive discussion of the Open Financial Exchange
synchronization mechanism.

The client follows the steps below to perform a synchronization:

1. The client sends a
<PMTSYNCRQ> and/or <RECPMTSYNCRQ> containing the token
it has stored from its last successful synchronization (or the
special initial token value).

2. The client processes
the <PMTSYNCRS> and/or <RECPMTSYNCRS> response from
the server.

When the client has requested the server to add a
transaction, a response that contains a <TRNUID> matching
a transaction originally sent by the client-for which the client
has not recorded an associated <SRVRTID>-is the normal scenario.
This scenario could also occur if the server response did not
reach the client in the previous session. In either case, the
client should add these server IDs to their associated transactions
at this point.

If the client previously recorded the <SRVRTID>,
this response is a change in status or in the contents of the
transaction. The request might have originated from this client,
another client, or might be the result of server processing.

If the <TRNUID> does not match any transaction
known to the client, a second client initiated this transaction.
In rarer cases the response might be a transaction initially requested
by this client, for which the client has lost its record; for
example, the client has reverted to a backup.

The diagram below describes the processing and interpretation
of <SRVRTID> and <TRNUID> identifiers by the client:

After the server has processed all the synchronization
responses, the client scans its database of transactions to verify
that they have all been assigned a <SRVRTID>. Any transactions
missing this identifier were never received by the server and
should be resent (using the originally assigned <TRNUID>
to avoid duplicate requests). Additionally, the client should
record the <TOKEN> received in the response.

Open Financial Exchange separates messages that the
client and server send into groups called message sets. Each financial
institution defines the message sets that a particular institution
will support. Currently, all the payment messages described in
this chapter fall into a single message set.

The message set contains options and attributes that
allow a financial institution to customize its use of Open Financial
Exchange. The options and attributes are defined in the profile
as part of the message set definition. Each set of options and
attributes appears within an aggregate that is specific to a message
set. Specifically, all of the options and attributes that pertain
to payments are contained within <PMTMSGSETV1>.

Transactions - a combination of bank transaction
detail records and investment transaction detail records. Transactions
only within the specified start and stop dates are sent.

Positions - positions a user has at a brokerage.
Each statement response must contain a complete set of position
records, even if no transactions occurred in the requested statement
period for a particular holding.

Balances - current balances typically reported
on an FI statement, such as cash balance or buying power. They
can also convey other numbers of interest, such as current interest
rates.

Open Orders - current open trading orders that
a user has at a brokerage.

Securities - any security referenced in either
transactions, positions, open orders or explicitly requested.

Many FIs distinguish between activity and positions
in cash, margin, and short accounts, with some FIs having many
other types of "sub-accounts." Open Financial Exchange
defines four standard types of sub-accounts: Cash, Margin, Short,
Other. Position, Transaction, and Open Order records identify
the sub-account.

Chapter 3 describes how to use positive and negative
numbers. Briefly, 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.

Many FIs provide investment accounts that allow users
to write checks and perform other traditional banking transactions,
as well as investment transactions. Open Financial Exchange requires
FIs to indicate in the download whether check writing privileges
exist for a given account.

FIs need to use the correct transaction record, bank
or investment, for each real-world transaction. Use the following
guidelines:

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 affect 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.

In this case, the money market fund is in its own
account with its own account number, distinct from the investment
account. In Open Financial Exchange, you should model the money
market fund as a separate money market bank account; see Chapter
11. The banking <STMTRQ> request aggregate and <STMTRS>
response aggregate will be used to download transactions.

Open Financial Exchange uses the money market as
a "sweep" account, where cash is "swept" as
needed when buying and selling securities. The money market fund
does not have its own account number. The customer sees the money
market fund as an investment-account cash balance. In Open Financial
Exchange, checks, ATMs, electronic fund transfer, deposit, and
withdrawal transactions should be downloaded using banking transactions
within the investment account. However, the sweep transactions
in and out of the money market fund should not be downloaded to
the client.

The customer purchases the money market fund and
is held in the account as a position. The money market fund does
not have its own account number. In Open Financial Exchange, the
money market fund should be returned as a <POSOTHER> position
in the <INVPOSLIST>, with a <UNITPRICE> of 1.00 and
<UNITS> as the current value of the position. Purchases
and redemptions should be modeled as <BUYOTHER> and <SELLOTHER>
transactions with a <UNITPRICE> of 1.00 and <UNITS>
as the transaction amount.

Investment accounts include brokerage accounts, mutual
fund accounts, 401K accounts, and other retirement accounts. Open
Financial Exchange supports transactions, positions, balances,
and open orders for all of these account types.

Open Financial Exchange separates messages that the
client and server send into groups called message sets. Each financial
institution defines the message sets that the institution supports.
The messages described in this chapter fall into two message sets:

Investment Statement Download

Security Information

Each message set contains options that allow a financial
institution to customize its use of Open Financial Exchange. For
example, an institution can support the Investment Statement Download
Set (INVSTMTMSGSETV1), but it can choose not to support the download
of open orders.

The options and attributes are defined in the profile
as part of each message set definition. Each set of options and
attributes appears within an aggregate that is specific to a message
set. For example, <INVSTMTMSGSETV1> contains all the options
and attributes that pertain to investment statement download.

In an Open Financial Exchange file there can be more
than one investment statement download request. All investment
statement requests for the Open Financial Exchange file must be
contained within the INVSTMTMSGSRQV1 aggregate.

In an Open Financial Exchange file there can be more
than one investment statement download response. All investment
statement responses for the Open Financial Exchange file must
be contained with in the INVSTMTMSGSRSV1 aggregate.

Securities must be consistently identified to allow
client applications to prepare accurate investment reports across
all user investment accounts, even at multiple FIs. At this time,
neither a security name nor its symbol is standardized. Therefore,
Open Financial Exchange uses CUSIP numbers (a unique 9-digit alphanumeric
identifier) to identify securities. CUSIP numbers are available
for the vast majority of securities traded today, including those
without symbols such as bonds. For a security that does not have
a CUSIP, a financial institution must follow the standard procedure
of assigning a CUSIP by using itself as the issuer to avoid conflict
with any other CUSIP.

Tag

Description

<SECID>

Security-identifier aggregate

<UNIQUEID>

Unique identifier for the security. CUSIP for US FIs

<UNIQUEIDTYPE>

Name of standard used to identify the security i.e., "CUSIP" for FIs in the United States

Non-US financial institutions that do not have access
to CUSIP numbers must supply a unique identifier for each security
in the UNIQUEID field of this aggregate. Open Financial Exchange
will be expanded to include other security identifying standards.

The user can use the SECLISTTRNRQ and SECLISTRQ aggregates
to request information about specific securities. The SECLISTTRNRQ
is the transaction-level aggregate that contains the SECLISTRQ.
The SECLISTRQ aggregate specifies for which securities information
is being requested.

If the client sends a security list request to an
FI, then the server must send back a security list response to
the client application. The security list response is used primarily
to report the status of the security list request. The actual
security information should be sent in the security list SECLIST
aggregate described in section 13.8.4.

The security list response aggregate is an empty
aggregate that is used to respond to the <SECLISTRQ>. It
is used to signify that the security list is generated as a result
of a security list request. The actual security information should
be included in the <SECLIST> aggregate.

In response to a SECLISTTRNRQ sent by a client
application where the SECLIST should contain information for each
security specified in the SECLISTTRNRQ.

When the response file contains an investment
statement download that has positions, transactions, or open orders.
The SECLIST should contain information about security referenced
in the investment statement download. Clients are completely dependent
on the security list to provide descriptive information for the
securities referenced in positions, transactions, and open orders.

Tag

Description

<SECLIST>

Security-list-request aggregate

<DEBTINFO>

Debt security information aggregates. (zero or more), see 13.8.5.2

</DEBTINFO>

<MFINFO>

Mutual fund information aggregates. (zero or more), see 13.8.5.3

</MFINFO>

<OPTINFO>

Option information aggregates. (zero or more), see 13.8.5.4

</OPTINFO>

<OTHERINFO>

Other security type information aggregates. (zero or more), see 13.8.5.5

The <MFINFO>, <STOCKINFO>, <OPTINFO>,
<DEBTINFO>, and <OTHERINFO> aggregates provide security
information. They define the type of security, and one or more
sets of descriptive information. These aggregates relate the <SECID>
used in positions, transactions, and open orders to descriptive
information about those securities. In this way, the system describes
a given security only once, no matter how many times it is referenced.

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 transaction IDs supplied by FIs, Open Financial Exchange
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.

Investment statement download can be requested using
the INVSTMTTRNRQ and INVSTMTRQ aggregates. The INVSTMTTRNRQ is
the transaction level aggregate that contains the INVSTMTRQ. The
INVSTMTRQ aggregate specifies what types of information to include
in the statement download and from which account to download the
information.

The following table shows the Investment Statement
Request record. It is similar to a bank statement request, except
that there are extra tags to indicate which pieces the user desires.
Note that because transaction and position requests require date
information, they use aggregates, whereas the other requests are
elemental of type Boolean.

Clients and servers should interpret <DTSTART>
and <DTEND> as described in Chapter 3.

The response can contain transaction, position, open
order, and/or balance detail records; each in its own aggregate.
The transaction list aggregate can contain a mixture of bank statement
records and investment transactions, as specified below.

Tag

Description

<INVSTMTRS>

Investment-response aggregate

<DTASOF>

As of date & time for the statement download, datetime

<CURDEF>

Default currency for the statement

<INVACCTFROM>

Which account at FI

</INVACCTFROM>

<INVTRANLIST>

Begin transaction list (at most one)

<DTSTART>

Start date for transaction data, datetime

<DTEND>

This is the value that should be sent in the next <DTSTART> request to insure that no transactions are missed, datetime

For investment statement download, margin call information
should be included in the balances section. Margin call information
should be contained in a <BAL> aggregate and included in
the balance list <BALLIST>.

In investment statement download, two transactions
are needed to reflect mutual fund exchanges. A SELLMF should be
generated for the mutual fund being switched from and a BUYMF
should be generated for the mutual fund being switched to. You
can use the RELFITID tag to link these two transactions to each
other. You should use the MEMO tag of the individual transactions
to explain that a mutual fund exchange occurred.

Notes on Corporate Actions

Since corporate actions can often be very complicated,
it is difficult to define a single action aggregate that encompasses
all possible scenarios. Instead, you should describe corporate
actions using one or more of the provided basic action types.
You should use the memo field of the individual transactions to
link transactions to an encompassing corporate action.

Notes on Option Splits

When the underlying security for an option splits,
a new security is generated for the option since the strike price
changes. In investment statement download, you need two transactions
to reflect this activity. There should be a TRANSFER transaction
to show that the old option security is removed from the account
and another TRANSFER transaction to show that the new option security
is moved into the account.

Notes on Option actions

For options, the overall sequence of actions is as
follows:

For an option writer:

Position is opened with Sell to Open.

Position is closed with one of the following:
Buy to Close
Expire
Assigned

For an option buyer:

Position is opened with Buy to Open.

Position is closed with one of the following:
Sell to Close
Expire
Exercise

Position records represent a user's current positions,
regardless of the transactional history. Prices and values should
be the most recent available, even if different from a transaction
price on the same day.

In position records, securities are identified as
being either short or long. Because each FI has different rules
regarding which sub-accounts can be used for short compared to
long activity, FIs must explicitly indicate the type of position
in addition to specifying the sub-account where the position takes
place.

For options, position type SHORT is equivalent to
WRITING an option, and position type LONG is equivalent to HOLDING
an option. For security types where there is only one type (for
example, bonds), use LONG.

General Position Information <INVPOS>

The INVPOS aggregate contains fields relevant to
all investment position types. It is included in the position
aggregates as shown in the following sections.

The <INVBAL> aggregate contains five specific
balances: Margin sub-account, Cash sub-account, Short sub-account,
Other sub-account, Buying power. It can also contain a <BALLIST>
aggregate that contains one or more <BAL> aggregates. The
<BAL> aggregate (see Chapter 3) allows an FI to send any
number of balances to the user, complete with description and
Help text. The intent is to capture the same type of balance information
present on the first page of many FI brokerage statements. You
can also use the <BAL> aggregate to send margin call information.

Open Financial Exchange currently defines one investment
e-mail message that clients can send to an FI. With this message,
the user can prepare a message to the FI regarding one of their
accounts. The server acknowledges receipt of the message. The
FI prepares the response that the client picks up when it synchronizes
with the server. E-mail is subject to synchronization, using <INVMAILSYNCRQ>
/ <INVMAILSYNCRS>.

This user has one investment transaction, one bank
transaction, one open order, two position entries, and one balance
entry. The user deposits some money and buys shares in Acme. The
user has an open limit order to buy 100 shares of Hackson Unlimited
at $50/share. The holdings show the user already had 100 shares
of Acme and now has 200 shares. The user also has one option contract
to sell Lucky Airlines shares, bought before this download.