1-Way ofx and Microsoft Money Microsoft Corporation June 3, 2005 What is 1-Way ofx?

Common Elements

1. Financial Institution Transaction ID

An FI assigns an to uniquely identify a financial transaction that can appear in an account statement. Its primary purpose is to allow a client to detect duplicate responses. Open Financial Exchange intends for use in statement download applications, where every transaction requires a unique ID; not just those that are client-originated or server-originated.

FITIDs must be unique within the scope of the requested transactions (that is, within an account) but need not be sequential or even increasing. Clients should be aware that FITIDs are not unique across FIs. If a client performs the same type of request within the same scope at two different FIs, clients will need to use FI + account + as a unique key in a client database.

NOTE: Although the specification allows FITIDs of up to 255 alphanumeric characters, client performance may significantly improve if servers use fewer characters. It is recommended that servers use 32 characters or fewer.

Usage: Bank statement download, investment statement download

2. Server-Assigned ID

A is a server-assigned ID for an object that is stored on the server. It should remain constant throughout the lifetime of the object on the server. The client will consider the SRVRTID as its “receipt” or confirmation and will use this ID in any subsequent requests to change, delete, or inquire about this object.

Where the context allows, a server can use the same value for a given server object for both and , but the client will not know this. SRVRTIDs need to be unique only within the scope of the requests and responses they apply to, such as an account number. Like , a is not unique across FIs and clients might need to use FI + if a client requires a unique key.

Usage: Payments, Banking

3. Client-Assigned Transaction UID

4. Token

5. Transaction Amount

Open Financial Exchange uses in any request or response that reports the total amount of an individual transaction.

6. Memo

A provides additional information about a transaction.

7. Date Start and Date End

Clients use these tags in requests to indicate the range of response that is desired. Servers use these tags in responses to let clients know what the FI was able to produce.

In requests, the following rules apply:

• 
  If is absent, the client is requesting all available history (up to the , if specified). Otherwise, it indicates the inclusive date and time in history where the client expects servers to start sending information.
  
• 
  If is absent, the client is requesting all available history (starting from , if specified). Otherwise, it indicates the exclusive date and time in history where the client expects servers to stop sending information.
  

• 
  is the date and time where the server began looking for information, not necessarily the date of the earliest returned information. If the response is later than the requested , clients can infer that the user has not signed on frequently enough to ensure that the client has retrieved all information. If the user has been calling frequently enough, in the response will match in the request.
  
• 
  is the date and time that, if used by the client as the next requested , it would pick up exactly where the current response left off. It is the exclusive date and time in history where the server stopped looking for information, based on the request rules.
  

8. Common Data Types

   1. Dates, Times, and Time Zones

YYYYMMDDHHMMSS.XXX [gmt offset:tz name]

2. Date and Datetime

Specified date or datetime	Assumed defaults
YYYYMMDD	12:00 AM (the start of the day), GMT
YYYYMMDDHHMMSS	GMT
YYYYMMDDHHMMSS.XXX	GMT

Take care when specifying an ending date without a time. If the last transaction returned for a bank statement download was Jan 5 1996 10:46 a.m. and if the was given as just Jan 5, the transactions on Jan 5 would be resent. If results are available only daily, then just using dates and not times will work correctly.

Some services extend the general notion of a date by adding special values, such as “TODAY.” These special values are called “smart dates.” Specific requests indicate when to use these extra values, and list the tag as having a special data type.

3. Time

HHMMSS.XXX[gmt offset:tz name]

The milliseconds and time zone are still optional, and default to GMT.

4. Time Zone Issues

Although most transactions are not sensitive to the exact time, they often are sensitive to the date. In some cases, time zone errors lead to actions occurring on a different date than intended by the customer. For this reason, servers should always use a complete local time plus GMT offset in any datetime values in a response. If a customer’s request is for 5 p.m. EST, and a server in Europe responds with 1 a.m. MET the next day, a smart client can choose to warn the customer about the date shift.

Clients that maintain local state, especially of long-lived server objects, should be careful how they store datetime values. If a customer initiates a repeating transaction for 5 p.m. EST, then moves to a new time zone, the customer might have intended that the transaction remain 5 p.m. in the new local time, requiring a change request to be sent to the server. If, however, the customer intended it to remain fixed in server time, this would require a change in the local time stored in the client.

9. Amounts, Prices, and Quantities

   1. Basic Format

This section describes the format of numerical values used for amounts, prices, and quantities. In all cases, a numerical value that does not contain a decimal point has an implied decimal point at the end of the value. For example, a numerical value of “550” is equivalent to “550.”

The following types are defined to have a maximum of 32 alphanumeric characters, including digits and punctuation. However, clients and servers may have specific limits for the maximum number of digits to the left or right of a decimal point. If a server cannot support a client request due to the size or precision of a number, the server should return status code 2012.

Amount: Amounts that do not represent whole numbers (for example, 540.32), must include a decimal point or comma to indicate the start of the fractional amount. Amounts should not include any punctuation separating thousands, millions, and so forth. The maximum value accepted depends on the client.

Quantity: Use decimal notation.

Unitprice: Use decimal notation. Unless specifically noted, prices should always be positive.

Rate: Use decimal notation, with the rate specified out of 100%. For example, 5.2 is 5.2%.

Some services define special values, such as INFLATION, which you can use instead of a designated value. Open Financial Exchange refers to these as “smart types,” and identifies them in the specification.

2. Positive and Negative Signs

• 
  Investment buy amount, investment sell quantity
  
• 
  Bank statement debit amounts, checks, fees
  
• 
  Credit card purchases
  
• 
  Margin balance (unless the FI owes the client money)
  

• 
  Investment sell amount, investment buy quantity
  
• 
  Bank statement credits
  
• 
  Credit card payments
  
• 
  Ledger balance (unless the account is overdrawn)
  

10. Language

11. Other Basic Data Types