Introduction

Audience

Document Overview

Related Documentation

This specification details the OFC data format and how the next release of Microsoft Money will use OFC. Following the introduction, this specification is divided into the following sections:

Chapter 1

Chapter overview

• Microsoft Money will use standard, Internet protocols to communicate with a bank’s server.
• Money will use Hypertext Transfer Protocol (HTTP) to transfer data in the OFC format between Microsoft Money and a bank’s server.
• Money will use Secure Sockets Layer (SSL) or Private Communications Protocol (PCT) to secure the communication channel between Microsoft Money and a bank’s server. A bank must choose one security protocol for their server.
• Microsoft Money can connect to a bank’s server using the Internet or using a private network. A bank must choose one connection method.
• Microsoft Money operates in a batch mode. This means that a Money user will queue up transaction requests, connect to a bank’s server, and Money will send all of the user’s transactions requests to the bank’s server. While the user is connected to the server, the server is expected to process all of these requests and send responses back to Microsoft Money.

POST URL HTTP/1.0

Connection: Keep-Alive

Pragma: no-cache

User-Agent: XSOFC Driver 1.0

Content-Type: application/x-ofc

Content-Length: length in bytes of OFC file

<OFC>

</OFC>

Implementation notes on HTTP POST:

• The first line of the HTTP request will contain POST, the URL of the server Money is sending OFC files, and HTTP/1.0. For example:
  POST ofc.bank.com/ofcisa.dll HTTP 1.0
• Content-Length should include the size of data (in bytes) in the OFC format.
• Following Content-Length will be a carriage-return and line feed.
• Following the carriage return and line feed will be data in the OFC format. This will start with the <OFC> tag and end with the </OFC> tag. The value in Content-Length will specify the size of this data (in bytes.)

HTTP 1.0 statuscode statusstring

Content-Type: application/x-ofc

Content-Length: length in bytes of OFC file

<OFC>

</OFC>

Notes on HTTP response:

• The first line of the HTTP request will contain HTTP 1.0, the HTTP status code and a string describing the status code. For example:
  HTTP 1.0 200 OK
• The following HTTP statuscodes and statusstrings are supported by Microsoft Money:

• Content-Length should include the number of bytes in the OFC file. Money will read this number of bytes when processing the OFC response file.
• Following Content-Length will be a carriage-return and line feed.
• Following the carriage return and line feed will be data in the OFC format. This will start with the <OFC> tag and end with the </OFC> tag. The value in Content-Length will specify the size of this data (in bytes.)

A bank should take the following steps when supporting an Internet connection:

• Purchase an HTTP server that supports the SSL or PCT security protocols. The server must support the HTTP 1.0 protocol. Microsoft Internet Information Server (included in Windows NT Server) and Netscape Commerce Server are examples of HTTP servers that have been tested with Microsoft Money.
• Connect the server to the Internet. This may entail use of an Internet firewall.
• Define how the HTTP server will send data to the back-end host system. Most HTTP servers support the ability to run applications (CGI and ISAPI are two common ways to write a server-side application) on the server. A server application can receive the OFC data in the HTTP POST from Micrososft Money and then send the data to the host system. The application can also receive responses from the host and send these responses back to Money in the OFC format.
• Define a URL for the server. The URL is the Internet address of the server. An example URL is: http://ofc.bank.com/isapi.dll. This URL specifies a computer called "ofc" on the bank.com domain. The URL also points to a program running on the server called "isapi.dll."

Chapter 2

Chapter overview

• Every connection between Microsoft Money and a bank’s server will be secured using the SSL or PCT protocol.
• Money will secure Internet and private dial-up connections using SSL or PCT.
• A bank must choose one security protocol: SSL or PCT.
• North American releases of Money will use 128-bit encryption.
• International releases of Money will use 64-bit encryption.
• A bank must issue each Microsoft Money customer a User ID. The User ID should uniquely identify a user on the system.
• A bank must issue each Microsfot Money customer a password. Users will be required to enter their password each time they wish to connect to the server. The password will never be written to disk.

Any communication over a network exposes risk to each party involved in the communication and to the data sent over the network. These risks can be summarized as follows:

1. Private and confidential information sent between client and server could be intercepted.
1. Private and confidential information stored on a bank’s host system can be accessed by unauthorized individuals.
1. An attacker can impersonate a user and conduct transactions on behalf of that user.
1. Harmful code could be sent from the server to the client, possibly causing problems on the client computer.
1. Harmful code could be sent from the client to the server, possibly causing problems on the server computer.

Both PCT and SSL use public-key encryption to secure a channel between client and server. Before any OFC data is sent, Money and the bank’s server will negotiate a session key that is used to encrypt the session. Once a session key has been agreed upon and the session is secure, Money will send an OFC file to the server.

Each session secured using PCT and SSL uses a different session key. If a session is compromised, this security breach is limited to one particular session. Compromising subsequent sessions will involve spending the same amount of effort as it took to compromise the first session.

Using a 128-bit key makes the communication between Money and a bank’s server significantly more secure than previous implementations of SSL that used 40-bit keys. These implementations were subject to "brute force" attacks where it was possible to try each of the 2⁴⁰ possible keys until you find the one that decrypts the message. Using longer 128-bit keys make calculations prohibitively more expensive.

SSL is currently available in the Netscape Navigator browser, Netscape Commerce Server, Microsoft Internet Explorer 2.0, 3.0 and Microsoft Internet Information Server. PCT will be supported in Microsoft Internet Explorer 3.0 and Microsoft Internet Information Server 1.1.

A bank can choose the solution that best meets their needs. For more information about PCT reference http://pct.microsoft.com or http://www.microsoft.com/internet. For more information about SSL reference http://www.netscape.com/newsref/std/SSL.html.

A bank can choose to communicate with Microsoft Money using a private dial-up network running the PPP protocol. Microsoft Money will use the same 128-bit (64-bit internationally) SSL or PCT security protocols to communicate on this type of network.

A bank should take the following steps to implement security:

• Install SSL or PCT on the HTTP server. Reference the server documentation for details on how to do this.
• Obtain a certificate for the server from VeriSign. The VeriSign home page (www.verisign.com) includes instructions on how to get a certificate for your HTTP server.

• Define a process for distributing User IDs and passwords to Microsoft Money users. For example, some banks may mail these to their users, while others may issue these over the telephone.

Chapter 3

The Branding Server is a server used by Microsoft Money to download details about the online services a bank chooses to offer its customers. The information stored on the Branding Server is provided by the bank and can be updated by the bank at any time. Microsoft Money users will be able to call the Branding Server free of charge.

Information downloaded from the Branding Server tells Money what online services are offered by a bank, how to connect to the bank, and also provides graphics to enhance the Money user interface with the bank’s logo and contact information.

Chapter overview

• Microsoft Money uses the Branding Server to find out how to connect to a bank’s server.
• The Branding Server will also download branding information that will customize the Money user interface with information provided by the bank.
• Money users will be able to call the Branding Server free of charge.

If a bank has chosen to offer online services to its customers using OFC, the Branding Server will download information telling Microsoft Money how to connect to the bank. This section details the information Money will download from the Branding Server to support an OFC connection.

Money will also download other information such as logos and contact information. A specification for this information will be posted on the Microsoft web site at http://www.microsoft.com/industry/bank/online.htm.

Notes on the Branding Server data file

• (DaysPre- + DaysPost-) = OFC’s DAYSREQD value. DAYSREQD is commonly referred to as days-to-pay.
• Contact Microsoft for information on how to submit bank information to the Branding Server.

Chapter 4

Chapter overview

• A user must setup Money for online services with a particular bank.
• Information downloaded from the Branding Server will instruct the user how to enroll for online services with a particular bank.
• When the customer enrolls for online services. a bank is expected to issue a User ID and password to the customer.

Chapter 5

Chapter overview

• Microsoft Money assumes that a bill payment service can issue a payment to any payee (business and individuals.)
• When entering a payment to a payee for the first time, Money users will be prompted for the payee’s name, address, city, state, zip code, phone number and account number with that payee.
• For first-time payments, Money will send a request to add the payee to the system with the request to issue a payment to the payee.
• When the server has added the payee to their system, the server can return an ID to reference the payee. If Money has an ID for a payee, it will use it to reference the payee in subsequent payment requests.
• The days-to-pay value defines the lead time required to deliver a payment to a payee by a desired due date. The default days-to-pay value is downloaded from the Branding Server and can be updated when the user connects to the bank’s server.
• The withdrawal date value defines the number of business days before a payment’s due date when funds are withdrawn from the user’s account. The default withdrawal date value is downloaded from the Branding Server and can be updated when the user connects to the bank’s server.
• Money users can send email to the bank to inquire on the status of an electronic payment.
• Money users can cancel payments that have not yet been processed.

Money will use the days-to-pay value to determine if the payment can be made by the due date. Money will add the number of days-to-pay for the payee to the current date (starting with tomorrow.) If the resulting date is less than or equal to the due date of the payment, the payment will be accepted and entered into Money’s account register. If the resulting date is greater than the due date due date of the payment, Money will inform the user that the payment cannot be made and suggest the earliest possible date.

For example, let’s assume that today is January 10^th and the user enters January 19^th as the desired due date of the payment. The payee the user wants to pay has a days-to-pay value of 5 days. January 10^th plus 5 days provides enough lead time to issue a payment by January 19^th.

Now the user wants to enter another electronic payment. Today is still January 10^th and the user enters January 12^th as the due date of the payment. The payee has a days-to-pay value of 5 days. In this case, Money will not allow the user to enter the payment since there is not enough time to get a payment to the payee by the 12^th. However, Money will suggest the next date the payment can be made (January 15^th.)

Days-to-pay is the amount of lead time (measured by the number of business days) required to issue a payment to a payee. Money will use this value to determine if a payment can be made by the due date of a payment.

A bill payment service’s default days-to-pay value will be downloaded from the Branding Server. This value will be used to validate payment dates for all new payees. At any time, the server can send Money a new default days-to-pay value using the <DAYSREQD> element in the OFC Signon response.

This value can also be specified by the server for each payee the user has paid electronically. The server must send Money a new days-to-pay value for a particular payee using the <DAYSREQD> element in the OFC Payee response.

Chapter 6

Chapter overview

• Online banking allows users to download statements, latest balances and transfer funds between accounts.
• Although some elements are optional in the OFC Statement response, it is suggested that the server include a CHKNUM, FITID and SRVRTID when they are available. Money uses these elements to prevent duplicate transactions in the Account Register. It is strongly suggest that a server include these elements in download bank statements.
• Online banking also allows users to send email to their bank.

Updating account information

For each account enabled for online banking, Microsoft Money will request the latest account balance and a list of transactions that have been posted to the account during every session with the server. A user can choose to disable these requests, but Money will enable them by default.

After the user has downloaded their statement, Money will help the user reconcile the statement against transactions they may have already recorded in their Account Register. The next section details how Money reconciles downloaded statements.

Money includes an algorithm that will attempt to match transactions that the user has entered in their Money Account Register to those that have been downloaded in STMTRS or ACCTSTMT records. This section describes what elements a server should return to facilitate Money’s matching algorithm.

• It is strongly recommended that each transaction have a CHKNUM value. Money will consider two transactions with the same CHKNUMs and amounts as identical transactions.
• It is strongly recommended that each transaction have a FITID element. Including these will prevent duplicate transactions from being recorded in Money’s Account Register.
• It is recommended that each transaction have a SRVRTID element if the transaction occured as the result of an online bill payment request from Money. Money will consider two transactions with the same SRVRTID to be identical transactions.
• If a server does not include CHKNUM, FITID, or SRVRTID there is a high likelihood of duplicate transactions recorded in a user’s Money Account Register. Duplicate transactions will make the user’s balances appear incorrect.

Chapter 7

Microsoft Money and a bank’s server communicate in a batch mode model where in a single session, Money will send a request file of OFC records to a server, the server will process this request file and return a response file of OFC records back to Money. During a session with a bank’s server, it is possible that the communication session will terminate prematurely.

Crash Recovery is the behavior built into Microsoft Money to ensure that duplicate transaction requests are not processed by the server and to minimize the amount of user uncertainty when the communication session is interrupted. Money uses the DTCLIENT element in the OFC Signon request record for crash recovery.

Chapter overview

• Crash recovery is designed to prevent transactions from being processed twice.
• Crash recovery means the behavior Money exhibits when a session with a server is not completed successfully due to a communication problem or server error.
• The server should use the DTCLIENT element in the Signon request record to determine if Money is calling in crash recovery mode or not.
• If the server receives the same DTCLIENT value that was sent in the previous Signon request, the server should assume Money is calling in crash recovery mode and sending the previous set of transactions again. The server should send the previous response file to Money. The server should not process the transactions in the request file.
• If the server receives a new DTCLIENT value in the Signon request, the server should process the transactions in the request file.

DTCLIENT and Money crash recovery behavior

To guarantee that transactions are not processed multiple times, the server should store the OFC request and response files of the previous session.

When the server receives a request file from Money, it should compare the value in the DTCLIENT element of the Signon request to the DTCLIENT element of the last request file.

If they are equal, the server should assume Money is calling in crash recovery and the server should not process the transactions in the request file and send the response file from the previous session back to Money. If the DTCLIENT values are not equal, the server should process the transactions and send a new response file back to Money.

Note: This section describes optional functionality for a server.

Money identifies each session with the server using the SESSKEY element in the OFC Signon record. The SESSKEY should be a value that uniquely identifies each user’s session between client and server.

A bank may want to make sure a user is calling their server in sequence by tracking SESSKEY values. If the user calls the server with an unexpected SESSKEY value, the bank can consider this to be an error and deny a user access to the server.

On the first call to an OFC server, Money will send a SESSKEY of zero (0) in the Signon request record. The server will process this request and send a Signon response back to Money. The Signon response from the server should include a SESSKEY value that will be sent in the next Signon request sent to the server.

On subsequent calls to the server, the Signon request sent from Money will include the SESSKEY value that was returned in the last session’s Signon response.

As an extra layer of security, the server can treat SESSKEY as session sequence numbers. The server should maintain the current and previous SESSKEY values.

If the user is calling with a SESSKEY that is unexpected (not the current or previous SESSKEY,) the server can reject the transactions in the request file. The server should return a Signon response record with a STATUS of 103 (Bad SESSKEY.) Based on this STATUS code, Money will display an error message to the user asking them to call their bank.

When the user calls their bank, it is expected that the bank will re-authenticate the user and then configure the server such that the next time the user connects, the server will process the transactions in the request file.

Notes:

• When returning a STATUS of 103 in the Signon response, the server should return a response file with only a Signon response. The SESSKEY element in the Signon response should echo the SESSKEY sent in the request.

Chapter 8

This chapter includes an introduction and some general notes about how Microsoft Money uses the OFC data format.

The OFC data format is composed of a set of records, each designed to represent a particular type of transaction between Microsoft Money and a server.

OFC is designed in a request-response model. OFC records come in pairs; each transaction includes a request and a response. The request transaction is designed to ask the server a question, the response will provide the answer. For example, one OFC transaction request asks the server for the latest balance of an account, and the response delivers the account balance to Microsoft Money.

Chapter overview

• OFC is a tagged file format based on SGML.
• Microsoft Money requires OFC files to be structured in a particular way. This structure is described in the Order of records (batch mode) section.
• OFC includes three different elements to uniquely identify transactions: CLTID, SRVRTID, and FITID.

Notes:

Unsolicited responses

Two OFC records can be sent "unsolicited" from server to client. Unsolicited responses do not have a corresponding request in the session.

The Payee response <PAYEERS> and Mail response <MAILRS> can be sent unsolicited. Unsolicited transactions will have a CLTID of "0" and a STATUS of "4."

A Payee response can be sent unsolicited if the bill payment processor has new information about a payee that needs to be reflected in Money. A Mail response can be sent unsolicited if the answer to the user’s question was not available during the session.

Server defined error messages

Chapter 9

This section of the document details the structure and syntax of valid aggregates and elements in OFC. Aggregates are collections of elements, elements represent single pieces of data.

These aggregates and elements are refernced in the subsequent pages of this spec that detail specific OFC records. This chapter is designed to be a reference, refer to each OFC record for details….

Notes on SERVICE:

• If SERVICE is 0 then Money will allow the user to download their bank statement for the account and transfer funds to other account enabled for online banking at the same bank.
• If SERVICE is 1 then Money will produce PAYMTRQ.
• If SERVICE is 2, Money will display bill payment user interface that will prompt a user for the following information:
• Interbank Transfers w/ payee id and payee bank account details. (INTERRQ w/ PAYEEID and ACCTTO)
• If SERVICE is 3 then Interbank Transfers w/ payee id (INTERRQ w/ PAYEEID
• If SERVICE is 4 then Interbank Transfers w/ payee bank account details. (INTERRQ w/ ACCTTO)

Notes on STMTTRN:

• The server should include either a complete PAYEE aggregate or a NAME, but not both.

Status <STATUS>

STATUS is used in responses to indicate the state of the request.

Transaction type <TRNTYPE>

TRNTYPEs are used to define the type of a transaction.

Notes on <TRNTYPE>:

• Including a TRNTYPE with a transaction will automatically assign an appropriate category to that transaction in Microsoft Money.

Chapter 10

OFC and Signon records are used to identify the OFC file and to authenticate a user on a server.

Tags displayed in bold are required by Microsoft Money.

OFC <OFC>

The OFC record contains the version of the OFC data format used to create the file.

Implementation details on <OFC>

• When using OFC with Microsoft Money 5.0, the <DTD> should be "2."
• The value for <CPAGE> should always be "1252." This is the code page that should be used to interpret the character data following a tag.

Signon Request <SONRQ>

The Signon request is designed to contain information to log the user into a server. This record can also be used to identify the session between client and server.

Notes on <SONRQ>

• Money will include data in the NEWPASS element if the user has chosen to change their password.

Signon Response <SONRS>

The Signon response answers the Signon request.

Notes on implementing <SONRS>:

• SERVICE updates the services supported by the server. The original default SERVICE value is downloaded from the Branding Server. If the server supports both services, then multiple SERVICE elements should be included.
• DAYSREQD updates the default days-to-pay value. The original default days-to-pay value is downloaded from the Branding Server.
• DAYSWITH updates the default withdrawal value. The original default withdrawal value is downloaded from the Branding Server.

When implementing the SONRS, follow these instructions based on the STATUS value returned:

If STATUS is 0

• A STATUS of 0 means that the entire batch of transactions sent from Money were accepted by the server.
• Include a date/time value of the server in the DTSERVER element.
• Include a new value in the SESSKEY element. Money will send this value to the server on the next call.

If STATUS is 5

• A STATUS of 5 means that the bank is asking the user to change their password on the next session with the server.
• A STATUS of 5 also means that the entire batch of transactions sent from Money were processed by the server.
• Include a date/time value of the server in the DTSERVER element.
• Include a new value in the SESSKEY element. Money will send this value to the server on the next call.

If STATUS is 100

• A STATUS of 100 means that the server has returned a message for the user in the ERROR element.
• The server should not return any other response transactions in the OFC response file. The file should only contain a SONRS. A STATUS of 100 means that the transactions sent in the request file were not processed.
• Include a date/time value of the server in the DTSERVER element.
• The server should include a message to the user in the ERROR element.
• The server should echo the value sent in the SESSKEY element of the Signon request.

If STATUS is 101

• STATUS of 101 means that the USERID sent in the Signon request was not valid.
• The server should not return any other response transactions in the OFC response file. The file should only contain a SONRS. A STATUS of 101 means that the transactions sent in the request file were not processed.
• Include a date/time value of the server in the DTSERVER element.
• The server should echo the value sent in the SESSKEY element of the Signon request.

If STATUS is 102

• STATUS of 102 means that the USERPASS sent in the Signon request was not valid.
• The server should not return any other response transactions in the OFC response file. The file should only contain a SONRS. A STATUS of 102 means that the transactions sent in the request file were not processed.
• Include a date/time value of the server in the DTSERVER element.
• The server should echo the value sent in the SESSKEY element of the Signon request.

If STATUS is 103

• STATUS of 103 means that the SESSKEY sent in the SONRS is not the last or expected session key. Banks who use the SESSKEY as a means of security should use this STATUS code.
• The server should not return any other response transactions in the OFC response file. The file should only contain a SONRS. A STATUS of 103 means that the transactions sent in the request file were not processed.
• Include a date/time value of the server in the DTSERVER element.
• The server should echo the value sent in the SESSKEY element of the Signon request. This will be sent in the Signon request of the next call.
• Money will display an error message to the user asking them to contact their bank. It is expected that the bank will reset the user’s SESSKEY on the server such that on the next call the server will accept any SESSKEY and return a new one in the SONRS.

If the user has changed their password

• If the server received a NEWPASS in the SONRQ and the user’s password was changed successfully, the server should also send back the following record:

<MAINTRS>

<STATUS>4

<MAILRS>

<MEMO>Your password has been successfully changed.

</MAILRS>

</MAINTRS>

<MEMO>Your password was not changed.

Chapter 11

Account records are used to describe the online services available for a user’s account.

Microsoft Money will send the server an Account request after the user enables or changes the online services for a particular account. The server is expected to return an Account response with the status of the user’s accounts on the server.

Tags displayed in bold are required by Microsoft Money.

Account request <ACCTRQ>

The Account request can be used to enable, or change online services for a particular account.

Notes on implementing <ACCTRQ>:

• The CLTID is a unique transaction identifier assigned by Money.
• The ACCTFROM aggregate will describe the account referenced. ACCTFROM will include BANKID (account number), BRANCHID (in int’l releases of Money), ACCTID (routing number), and ACCTTYPE (type of account.)
• The ACTION in the SERVRQST aggregate specifies if the user is attempting to enable or disable online banking and/or online bill payment for the account described in ACCTFROM.
• Two SERVRQST aggregates will be included. One will reference the status of Online Banking services for an account and the other will reference the status of Online Bill Payment services for an account.

When implementing the ACCTRQ, follow these instructions:

If ACTION is 0:

• An ACTION of 0 means the user has enabled an account for online services in Money that has not been previously enabled.
• The SERVRQST aggregate will describe what services the user has enabled for the account referenced in the ACCTFROM aggregate. See the note above about the possibilty of multiple SERVRQST aggregates.

If ACTION is 2:

• An ACTION of 2 means the server has already received an ACCTRQ with an ACTION of 0 for the account referenced in ACCTFROM.
• An ACTION of 2 entails that the user has changed the SERVICEs defined in the SERVRQST aggregate. This means that a user has enabled or disabled online banking and/or online bill payment for a specific account in Money. See the note above about the possibilty of multiple SERVRQST aggregates.
• If the user has disabled online bill payment and/or online banking for an account that has pending transactions or unreconciled statement transactions, Money will alert the user, telling them that disabling the account will prevent the user from inquiring on transactions or reconciling statements.

Account response <ACCTRS>

The Account response record answers the Account request. The Account response tells the client what online services are available for a particular account.

Notes on implementing <ACCTRS>:

• A SERVAUTH aggregate must be present for each SERVRQST in the ACCTRQ.
• If the user has attempted to enable a SERVICE in the ACCTRQ that is not supported by the server, the server should return an unsolicited MAILRS explaining that the SERVICE is not available to the user.

Chapter 12

Mail records are used to send messages between the user and their financial institution.

Microsoft Money will allow a user to generate email up to 18 lines long with up to 60 characters per line. Mail from server to Money can be up to 36 lines long, with up to 60 characters per line.

Tags displayed in bold are required by Microsoft Money.

Mail request <MAILRQ>

The Mail request record includes information describing the type of mail as well as the contents of the message.

Implementation notes on <MAILRQ>

• If the ACCTFROM aggregate is included, it will contain a BANKID, ACCTID, ACCTTYPE. Int’l releases will also have a BRANCHID.
• SERVICE will distinguish mail about online banking from mail about online bill payment.
• A <MEMO> element will be generated for each sentence the user types in followed by a carriage return.
• Money will include the following <MEMO> elements by default:

<MEMO>To: Customer Service
<MEMO>Subject: Subject

If <SERVICE> is 0

• The mail is in reference to a particular account that is enabled for online banking.
• The ACCTFROM aggregate will be filled in with a description of the account.

If <SERVICE> is 1

• The mail is in reference to a online bill payment.
• The ACCTFROM aggregate will NOT be in the MAILRQ.

Notes on <MAILRS>

• Information included in the MEMO field should be as complete as possible. For instance, if the MAILRS is answering a PAYIQRQ (Payment inquiry), then the MEMO should include the payment’s due date, amount, payee in addition to a description of the status of the payment.
• Unsolicited mail responses should contain a STATUS of "4" and a MEMO.
• The server should include a MEMO for each line of text that should be followed by a carriage return, line feed.

Chapter 13

Notes on <STMTRQ>

• The ACTION will always be zero (0.)
• On the first call to the server DTSTART will be set to (Current date - 1 month). This will enable a user to download some account history into their Money file on the first call to the server.
• Subsequent calls to the server will use the date of the last session in DTSTART.
• The server should send all transactions posted on or after the date in DTSTART.
• DTEND will be the current date of the client computer.

Statement response <STMTRS>

The Statement response record provides Money with a list of posted transactions and the latest account balance.

Notes on <STMTRS>

This table details where each STMTRS element is recorded in a Money Account Register transaction.

• The server should compose a STMTRN aggregate for each transaction in the statement.
• If the server can track the SRVRTID from a bill payment transaction, the server should return the SRVRTID in the statement. Money will use the SRVRTIDs to prevent duplicate transactions in the Account Register.
• FITIDs are used to match previously downloaded transactions with newly downloaded transactions. If two transactions have the same FITID, Money considers them to be the same transaction. If the server includes a FITID, the user will never have duplicate transactions entered in their Account Register.
• CHKNUMs should be included for check transactions. Money uses CHKNUMs to match downloaded transactions with those entered in the Account Register. Money allows CHKNUMs to be up to 8 characters.
• Reference Appendix One for a listing of supported SIC codes. Including a SIC code with a transaction will automatically categorize it in Microsoft Money, saving the user time and effort when reconciling their downloaded statement.
• If a PAYEEID is included, Money will use it to determine a payee for the transaction.
• Either a complete <PAYEE> aggregate or a <NAME> can be included. The user will be able to better reconcile their downloaded statement if a <PAYEE> or <NAME> is included.
• <MEMO> can include a description of the transaction.
• If the user’s balance is zero, include 0.00 in the LEDGER element.
• If the server has returned multiple NAME elements, Money will display them as "Name, name, name"

Notes on credit card statements:

A server should follow these instructions when returning credit card statement data:

• Credits should be positive amounts. Credits include payments the user has made to lower their credit card balance.
• Charges should be negative amounts.
• If the user has an outstanding balance on their credit card, the LEDGER should be negative.
• Include a SIC code whenever possible. If a SIC code is included, Money will automatically assign a category to the transaction when the user reconciles their account.

If STATUS is 0

• STATUS of 0 means that the STMTRQ was processed successfully and the server has returned a <LEDGER> and possibly <STMTTRN> transactions.
• CLTID should echo the CLTID sent in the request.
• Include DTSTART and DTEND elements.

If STATUS is 1

• STATUS of 1 means that the STMTRQ was not processed successfully.
• CLTID should echo the CLTID sent in the request.

If STATUS is 100

• STATUS of 100 means that the STMTRQ was not processed successfully and the server has returned an explanation why this is the case in the ERROR.
• Include CLTID element.
• Include the error text in ERROR element.

If STATUS is 104

• STATUS of 104 means that the STMTRQ was not processed successfully because the account referenced in the ACCTFROM aggregate in the STMTRQ was incorrect or not found.
• Include CLTID element.

Intrabank Transfer request <INTRARQ>

The Intrabank Transfer request is used to transfer funds between accounts at the same bank. Both accounts must be enabled for online banking services in Money.

Notes on <INTRARQ>

• An ACTION of 0 means that the user has entered a funds transfer in Money and sent the transfer request to the server.
• The accounts defined in ACCTFROM and ACCTTO must have been enabled for online banking in Microsoft Money.

Intrabank Transfer response <INTRARS>

The Intrabank Transfer response is used to inform the user of the success or failure of their transfer.

Notes on <INTRARS>

• If DTPOSTED is not returned by the server, Money will assume that the funds are immediately available to the destination account.
• Unless a STATUS of "0" is returned in an INTRARS, Money will assume the transfer happened and that funds are available in the destination account.
• Money does not allow users to inquire on a transfer. If the server returns STATUS of 0, Money assumes the transfer occurred.

If STATUS is 0

• If STATUS is 0, it is assumed that the transfer happened and the funds are available in the account described in ACCTTO.

If STATUS is 1

• If STATUS is 1, it is assumed that the transfer did not happen. No funds should move between accounts.
• Include CLTID element.

If STATUS is 100

• If STATUS is 100, it is assumed that the transfer did not happen. No funds should move between accounts. The ERROR should explain the cause of the failure.
• Include CLTID element.
• Include explanation in ERROR element.

If STATUS is 104

• If STATUS is 104, it is assumed that the transfer did not happen. No funds should move between accounts. A STATUS of 104 means that the account specified in the ACCTFROM aggregate in the INTRARQ was not found on the server.
• Include CLTID element.

Notes on INTERRQ:

• This record can contain an ACCTTO or PAYEEID but not both.
• If ACTION is 1 or 2, Money will include a SRVRTID element.

Chapter 14

Online Bill Payment records correspond to the online bill payment features offered by Microsoft Money. Enabling online bill payment services for an account will allow the user to send electronic payments to any payee. Online bill payment will also allow the user to send email to the payment processor, inquire on the status of a previously sent payment, and cancel a payment.

Tags displayed in bold are required by Microsoft Money.

Payee request <PAYEERQ>

The Payee request record is sent from Money to the server when a user issues a payment to a payee for the first time. This record will also be sent when the user edits the details of an existing payee.

Notes on <PAYEERQ>

• Money will always send a complete PAYEE aggregate even if a PAYEEID is included.
• If the user is paying the payee for the first time, a complete PAYEE aggregate will be sent
• If the user enters an electronic payment to a payee for the first time (the user has not entered a payment to the payee previously) then Money will generate a PAYEERQ and a PAYMTRQ (Payment request). Both records will be sent to the server in the same session.
• It is possible that Money will send a PAYEERQ to the server without a PAYMTRQ. For example, if the user schedules an electronic payment in the future, Money will send a PAYEERQ to the server on the next call.

If ACTION is 0

• An ACTION of 0 means that the user has entered an electronic payment to a payee who does not exist in the user’s Money file.
• A PAYEEID will not be included.
• A complete PAYEE aggregate will be included.

If ACTION is 2

• An ACTION of 2 means that the user has changed the details of the payee in Microsoft Money.
• A user can not change the payee’s name. A user can change the payee’s address, city, state, zip code, phone number and their account number with the payee.
• A PAYEEID or complete PAYEE aggregate will be included.

Payee response <PAYEERS>

The Payee response record provides details about a payee from the server.

Notes on <PAYEERS>

• Reference the section of this document on Online Bill Payment with Microsoft Money and OFC for details on the DAYSWITH and DAYSREQD elements.

If STATUS is 0

• STATUS of 0 means that the payee has been added to the payment processing host system.
• If a PAYEEID is available for the payee, it must be present in the PAYEEID element.

If STATUS is 1

• STATUS of 1 means that the payee was not added to the payment processing system.
• The server should echo the CLTID value sent in the Payee request.

If STATUS is 4

• STATUS of 4 means that the PAYEERS is sent "unsolicited" to Money. This means that there wasn’t a corresponding PAYEERQ sent to the server.
• CLTID must be zero (0).
• A complete PAYEE aggregate or PAYEEID must be included.
• DAYSREQD and DAYSWITH must be included.

If STATUS is 100

• STATUS of 100 means that the that the payee was unable to be added to the payment processing system.
• CLTID should echo the CLTID in the PAYEERQ.
• An explanation of why the problem occurred should be in the ERROR element.

Payment request <PAYMTRQ>

For each electronic payment transaction the user enters in their Money account register, Money will send a Payment request for each transaction. The payment requests asks the bill payment service to make a payment to a specific payee by a particular date.

Notes on <PAYMTRQ>

• In Microsoft Money, users can enter 256 character memos for each transaction.
  Note: If the bill payment processor will not print this memo on the user’s checks, it should make the customer aware of this before they sign up for online bill payment.
• If Money has a PAYEEID for the payee, it will be included. If not, Money will send a complete PAYEE aggregate.
• PAYACCT will be included in every PAYMTRQ record.
• Money will send the payment’s due date in DTDUE. This value will be sent regardless of the payment model used by the payment processor (withdraw funds on the due date or withdrawn funds before the due date.)

If ACTION is 0

• An ACTION of 0 means that the user has entered an electronic payment in Money and is sending it to the server to be processed.
• Money will assign a CLTID value.
• The ACCTFROM aggregate will describe the account the user is using to pay the bill.
• TRNAMT will be the amount of the check.
• If Money has a PAYEEID, it will send it. If not, a complete PAYEE aggregate will be sent.
• PAYACCT will be the user’s account number with the payee.
• DTDUE will be the due date of the payment.
• MEMO will be the memo a user entered in the Money account register.

If ACTION is 1

• An ACTION of 1 is a request to delete the pending payment request from the bill payment server.
• An ACTION of 1 means that the user has sent the payment to the bill payment server, but the bill payment has not yet been processed.
• Money will assign a CLTID value.
• The ACCTFROM aggregate will describe the account the user is using to pay the bill.
• TRNAMT will be the amount of the check.
• If Money has a PAYEEID, it will send it. If not, a complete PAYEE aggregate will be sent.
• PAYACCT will be the user’s account number with the payee.
• DTDUE is the due date of the payment.
• MEMO will be the memo a user entered in the Money account register.
• A SRVRTID will be included. It will be the SRVRTID sent back to Money in the PAYMTRS when the payment was originally sent in for processing.
• If the payment has already been processed, Money will not allow the user to send a PAYMTRQ with ACTION of 1 to the server.

Payment response <PAYMTRS>

The Payment response record answers the Payment request, providing details about the payment.

Notes on <PAYMTRS>

• The SRVRTID is used when inquiring about a payment. It is displayed in the Money user interface as a "Confirmation #." It is assumed that a user can use this number when contacting a customer service representative about the status of the payment.

If STATUS is 0

• A STATUS of 0 means that the payment referenced in the PAYMTRQ has been accepted by the bill payment server and will be processed by the date in DTDUE.
• The CLTID should echo the CLTID sent in the PAYMTRQ.
• A SRVRTID must be returned.
• If a PAYEEID was sent in the PAYMTRQ, the server should echo it back in the response.

If STATUS is 1

• A STATUS of 1 means that the payment referenced in the PAYMTRQ has not been accepted by the bill payment server and will not be processed by the date in DTDUE.
• The CLTID should echo the CLTID sent in the PAYMTRQ.

If STATUS is 100

• A STATUS of 100 means that the payment referenced in the PAYMTRQ has not been accepted by the bill payment server and will not be processed by the date in DTDUE.
• The server should include as explanation why the payment was rejected in the ERROR.
• The CLTID should echo the CLTID sent in the PAYMTRQ.

Payment inquiry request <PAYIQRQ>

Money will allow a user to send email inquiring about the state of a previously sent payment.

Notes on <PAYIQRQ>

• Money will send the same SRVRTID that was returned in the PAYMTRS for the transaction. A SRVRTID will always be included in the PAYIQRQ.
• The MEMO element will contain the user’s question about the payment. A MEMO element will be generated for each line the user types in followed by a carriage return.
• Money will including the following MEMO elements by default:

<MEMO>To: Customer Service
<MEMO>Subject: Subject

The user is able to enter any text in the To: and Subject: fields in Money.

Notes on <PAYIQRS>

• For each PAYIQRQ sent from Money to the server, the server should at least send back a PAYIQRS with a STATUS of "0" to tell the user that their question was received and will be answered at a later date.
• If the answer to the user’s question is not available during the session, the bill payment processor can send the answer to Money in an unsolicited MAILRS when the answer is available. See the chapter on Mail records.
• The answer to the user’s question should be in the MEMO of the MAILRS. The MEMO should also reference the date, payee, and amount of the payment so the user is aware what payment is referred to.

Chapter 15

Notes on <ACCTSTMT>

• It is recommended that one OFC file contain data for one account. Microsoft Money will import the transactions for one account at a time.
• The information in the ACCTFROM aggregate is used to match the downloaded transactions with those already entered in Money. Money will mark each downloaded transaction as cleared in the user’s account.

Appendix one