2.2
|
OFX headers
|
Clarification
|
All OFX headers are required. NONE should be returned if client or server does not make use of an individual tag, e.g., COMPRESSION:NONE, OLDFILEUID:NONE
|
2.5.1.1
|
|
Clarification
|
NOTE: A client should use the anonymous form of and on those occasions when a server need not validate the , i.e.,
, .
The anonymous or value is left aligned and padded with 0 to a length of 32 characters: anonymous00000000000000000000000
|
2.5.1.1
|
|
Clarification
|
Servers must process a element in a . However, a server may decide does not afford sufficient security and may optionally not return a in the .
|
2.3.1
2.7
|
SGML compliance and Custom Tags
|
Clarification
|
Aggregates must have end tags and cannot have values.
Elements must have values (cannot contain only whitespace).
The DTD defines the order and usage of official OFX tags.
Custom tags must contain a dot and follow the xxx.yyy format. These tags are ignored if they are not recognized.
Tags without a dot are reserved for OFX use.
|
3.2.8
|
Dates and Times
|
Clarification
|
Vaild gmt offset values are in the range from –12 to +12 for whole number offsets. Formatting is +12.00 to -12.00 for fractional offsets, plus sign may be omitted.
|
3.2.9
|
Amount
|
Clarification
|
Trailing and leading spaces should be stripped. Number format uses a leading sign. Negative number format uses a minus sign (-).
|
6.4
|
Data Synchronization Specifics
|
Clarification
|
Servers should return TOKEN=-1 in the event they must respond with an error, but there is no wrapper inside the wrapper.
|
6.10
|
Lite synchronization and Refresh
|
Clarification
|
Lite synchronization servers do not support Refresh. TOKEN=0 is not the same as Refresh synchronization. Therefore, clients should not send Refresh to a lite synchronization server.
|
6.10.1
|
OLDFILEUID
|
Change
|
Clients must now include the OLDFILEUID and NEWFILEUID headers and may no longer leave the OLDFILEUID and NEWFILEUID values blank.
Clients should now set the header value to NONE, e.g. OLDFILEUID:NONE, where previously they would have omitted the header or left it blank.
The previous text “If OLDFILEUID is absent, the client is not requesting file based error recovery..”
becomes “If OLDFILEUID is set to ‘NONE’ the client is not requesting file based error recovery …”.
NOTE: Clients should set OLDFILEUID to zero (OLDFILEUID:0) to request file based error recovery on its first connection to a server.
|
6.10.1
|
NEWFILEUID
|
Clarification
|
If NEWFILEUID matches a previous request file the client is requesting error recovery. The request file identified by the NEWFILEUID must contain exactly the same set of transactions as the previous request file. Servers can reject the file if it contains new or modified transactions.
NOTE: Clients should disallow
transactions during error recovery.
|
7.1.4
|
Client Signon for Profile Requests
|
Clarification
|
NOTE: and/or may be set to lower case "anonymous" followed by 23 zeroes.
|
8.4
|
Enrollment and Password Acquisition
|
Clarification
|
NOTE: and/or may be set to lower case "anonymous" followed by 23 zeroes.
|
8.7
|
Name and Address Changes
|
Clarification
|
Modified and unmodified elements are submitted in a change user information request . The lack of inclusion of a field in a change user request when that field was previously populated implies its deletion on the server.
|
11.12.2.2
|
|
Clarification
|
Response contains only interbank transfers where the of the Sync response matches the of the .
|
11.3.2
|
|
Clarification
|
can be used even if the is not supported.
|
11.7.1.2
|
|
Clarification
|
The DTD does not require either or in an interbank transfer response. The spec is incorrect.
|
11.10.1.2
|
|
Clarification
|
The included in the should be set to the same value as the .
NOTE: this is the response to the recurring model only. Servers must still generate an for each instance of the recurring transfer.
|
12
|
Implicit requests
|
Clarification
|
Servers should generate explicit responses to implicit requests. In other words, implicit payee additions or modifications resulting from a new or changed payment should generate explicit payee add or payee change responses from the server.
Such explicit responses are only returned to the client in a SNYC response.
|
12.2.4
|
Identifying Payees
|
Clarification
|
Servers must always assign PayeeLstIDs to payees. Once PayeeLstIDs have been assigned, clients must always send the
, even if a Payee has both a
and a
.
|
12.5.2
|
Payee Info
|
Clarification
|
The DTD requires either
or
inside
. The spec incorrectly says that both are optional.
|
12.6.1.4
|
Payment Discussion
|
Clarification
|
Payment transactions that also contain an implicit payee transaction (change or add) are considered a single unit of work.
A failure of either causes a failure in both. This is true for payment creation, modification and deletion transactions.
|
12.6.2.5
|
Payment Modification Discussion
|
Clarification
|
Implicit payee changes contained in a payment modification transaction affect the individual payment. The changes are also propagated to the server’s payee list and affect subsequent payments to that payee.
NOTE: Explicit payee changes are not propagated to pending payments.
|
12.7.2
|
Recurring Payment Modification
|
Clarification
|
Clients can modify both elements in the aggregate, i.e. and . Clients should send the original number of payments scheduled if there is no change. If there is a change in the number of payments scheduled clients should send the new number of payments.
Clients must account for pending payments and the server’s ModPending flag. This can result in implicit payment deletions.
|
12.9.2
|
Payee Modification
|
Clarification
|
Explicit payee modifications are made in the server’s payee list. They are not propagated to already created pending payments. Recurring Payments created after the Payee modification will use the updated information from the server’s payee list.
Implicit payee modifications contained within a payment creation, modification or deletion request are propagated to the payment and to the server’s payee list.
|
12.9.3
|
Payee Deletion
|
Clarification
|
Clients send the
in the
aggregate to delete an entire Payee.
To modify or delete specific payee information, clients should use the
and the
elements in the
.
|
12.11.2
|
|
Clarification
|
indicate days to exclude when calculating dates that utilize other bill payment bits, such as and values.
|
13.3.3.
|
Signs
|
Clarification
|
and are signed from the perspective of the user (positive for SELLs, negative for BUYs). All other Investment transaction amounts are always positively signed. In other words , , , , , , and are always positive numbers.
A positive , , , , or increased the negatively signed on a and decreased the positively signed on a .
and increase or decrease, respectively, the .
Servers should return corrections to investment buys or sells as the opposite transaction type, e.g., a correction to a buy is returned as a sell.
A correction to or is returned as an .
|
13.6.1
|
Specifying the Investment Account
|
Clarification
|
Brokers should use the domain name of their company’s URL as the , e.g.,
If URL=www.broker.com
then BROKERID=broker.com
|
13.9.2.4.3
|
Investment Aggregate
|
Clarification
|
is a single transaction that contains both income and an investment transaction. If servers can’t track this as a single transaction they should return an transaction and an .
and are signed as for an investment buy. Corrections to a are signed as for an investment sell.
|
13.9.2.6.2
|
Investment Positions
|
Clarification
|
and are incorrectly specified as quantity. They must be positive whole numbers A-32 (INTTYPE as per the DTD).
|
Yüklə 0.98 Mb.