Ana səhifə

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

Yüklə 0.98 Mb.
ölçüsü0.98 Mb.
1   2   3   4   5   6   7   8   9   10   ...   13

Common Elements

This section defines elements used in several services of Open Financial Exchange. The format of the value is either alphanumeric (A-n) or numeric (N-n) with a maximum length n; or as a named type. Section 3.2.8 describes the named types.
      1. Financial Institution Transaction ID

Format: A-255

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

      1. Server-Assigned ID

Format: A-10

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

      1. Client-Assigned Transaction UID

This does not apply to Active Statements.
      1. Token

This does not apply to Active Statements.
      1. Transaction Amount

Format: Amount

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

Usage: Bank statement download, investment statement download, payments
      1. Memo

Format: A-255

A provides additional information about a transaction.

Usage: Bank statement download, investment statement download, payments, transfers
      1. Date Start and Date End

Format: Datetime

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.

In responses, the following rules apply:

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

In all cases, servers are REQUIRED to use a “system add datetime” as the basis for deciding which details match the requested date range. For example, if an FI posts a transaction dated Jan 3 to a user’s account on Jan 5, and a client connects on Jan 4 and again on Jan 6, the server is REQUIRED to return that Jan 3-dated transaction when the client calls on Jan 6.

Usage: Bank statement download, investment statement download
      1. Common Data Types

        1. Dates, Times, and Time Zones

There is one format for representing dates, times, and time zones. The complete form is:

YYYYMMDDHHMMSS.XXX [gmt offset:tz name]

        1. Date and Datetime

Tags specified as type date or datetime and generally starting with the letters “DT” accept a fully formatted date-time-timezone string. For example, “19961005132200.124[-5:EST]” represents October 5, 1996, at 1:22 and 124 milliseconds p.m., in Eastern Standard Time. This is the same as 6:22 p.m. Greenwich Mean Time (GMT).

Date and datetime also accept values with fields omitted from the right. They assume the following defaults if a field is missing:

Specified date or datetime

Assumed defaults


12:00 AM (the start of the day), GMT





Note that times zones are specified by an offset and optionally, a time zone name. The offset defines the time zone.

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.

NOTE: Open Financial Exchange does not require servers or clients to use the full precision specified. However, they are REQUIRED to accept any of these forms without complaint.

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.

        1. Time

Tags specified as type time and generally ending with the letters “TM” accept times in the following format:

HHMMSS.XXX[gmt offset:tz name]

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

        1. Time Zone Issues

Several issues arise when a customer and FI are not in the same time zone, or when a customer moves a computer into new time zones. In addition, it is generally unsafe to assume that computer users have correctly set their time or time zone.

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.

      1. Amounts, Prices, and Quantities

        1. Basic Format

Format: A-32

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.

        1. Positive and Negative Signs

Unless otherwise noted in the specification, Open Financial Exchange always signs amounts and quantities from the perspective of the customer. Some typically negative amounts:

  • Investment buy amount, investment sell quantity

  • Bank statement debit amounts, checks, fees

  • Credit card purchases

  • Margin balance (unless the FI owes the client money)

Some typically positive amounts:

  • Investment sell amount, investment buy quantity

  • Bank statement credits

  • Credit card payments

  • Ledger balance (unless the account is overdrawn)
      1. Language

Language identifies the human-readable language used for such things as status messages and e-mail. Language is specified as a three-letter code based on ISO-639.
      1. Other Basic Data Types

Boolean: Y = yes or true, N = no or false.

currsymbol: A three-letter code that identifies the currency used for a request or response. The currency codes are based on ISO-4217. For more information about currencies, refer to section 5.2.

URL: String form of a World Wide Web Uniform Resource Location. It should be fully qualified including protocol, host, and path. A-255.
1   2   3   4   5   6   7   8   9   10   ...   13

Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur © 2016
rəhbərliyinə müraciət