OFC and Microsoft Money

This specification describes the OFC data format and details how Microsoft ® Money uses OFC for online home banking and online bill payment features.
Microsoft hereby grants to any party a royalty-free, worldwide, perpetual license to use the Open Financial Connectivity and Microsoft® Money Specification to make, use, and sell products and services that conform to this Specification.

Version 1.0.6
September 4, 1996

Contents

Introduction

Audience

Document Overview

Related Documentation

Microsoft Money and OFC

Chapter overview

HTTP

HTTP POST

HTTP response

Connectivity options

Internet

Private dial-up connection

Mode of operation

Batch mode

File import mode

Timeout values

Security

Chapter overview

Possible risks

Microsoft Money solutions

Secure communication protocols

PCT and SSL

Communicating over a private network

OFC User ID and Password

Implementing security

Microsoft Money and the Branding Server

Chapter overview

Identifying a financial institution

Defining information for the Branding Server

Setting Up for Online Services with Microsoft Money

Chapter overview

Setting up for online services with Money

Online Bill Payment with Microsoft Money and OFC

Chapter overview

Paying a bill in Microsoft Money

Entering an electronic payment

Validating the payment

Days-to-pay value

Withdrawal date value

Payee add behavior

Inquiring about a payment

Canceling a payment

Online Banking with Microsoft Money and OFC

Chapter overview

Updating account information

Matching downloaded transactions

Transferring funds

Microsoft Money, OFC and Crash Recovery

Chapter overview

DTCLIENT and Money crash recovery behavior

Server crash recovery behavior

Using the SESSKEY element to track sessions

OFC Data Format Details

Chapter overview

Introduction to the OFC format

Syntax

Structure

Order of records (batch mode)

Identifiers

Element lengths

Unsolicited responses

Server defined error messages

Illegal characters

Record structure with error responses

OFC Aggregates and Elements

Account <ACCTTO>, <ACCTFROM>

Account type <ACCTTYPE>

Action <ACTION>

Amount <AMOUNT>

Date and time <DTCLIENT>, <DTSERVER>

Online services <SERVICE>

Payee <PAYEE>

Statement transactions <STMTTRN>

Status <STATUS>

Transaction type <TRNTYPE>

OFC and Signon Records

OFC <OFC>

Signon Request <SONRQ>

Signon Response <SONRS>

Account Records

Account request <ACCTRQ>

Account response <ACCTRS>

Mail Records

Mail request <MAILRQ>

Mail response <MAILRS>

Online Banking Records

Statement request <STMTRQ>

Statement response <STMTRS>

Intrabank Transfer request <INTRARQ>

Intrabank Transfer response <INTRARS>

Interbank Transfer request <INTERRQ>

Interbank Transfer response <INTERRS>

Online Bill Payment Records

Payee request <PAYEERQ>

Payee response <PAYEERS>

Payment request <PAYMTRQ>

Payment response <PAYMTRS>

Payment inquiry request <PAYIQRQ>

Payment inquiry response <PAYIQRS>

File Import Records

Account statement <ACCTSTMT>

Standard Industrial Code support

Open Financial Connectivity (OFC) is a data format designed to represent financial transactions exchanged between client and server. The OFC format was designed to accommodate the requirements of a variety of banking and bill payment systems, both domestic and international.

The Microsoft Money 5.0 will support the OFC data format for its online home banking and online bill payment features.

Audience

This document is intended for use by banks and solution providers who are evaluating or implementing a home banking server solution using OFC and Microsoft Money.

Document Overview

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:

u Chapter 1, Microsoft Money and OFC

This explains how Microsoft Money will utilize the OFC data format for online home banking and online bill payment services.

u Chapter 2, Security

This explains how Microsoft Money will secure transactions sent from client to server.

u Chapter 3, Microsoft Money and the Branding Server

This explains the functionality of the Branding Server and how Microsoft Money utilizes it.

u Chapter 4, Setting Up for Online Services with Microsoft Money

This explains the process a user must go through to set up Microsoft Money for use with online services.

u Chapter 5, Online Bill Payment with Microsoft Money and OFC

This explains how Microsoft Money uses features of OFC for its online bill payment functionality.

u Chapter 6, Online Banking with Microsoft Money and OFC

This explains how Microsoft Money uses features of OFC for its online banking functionality.

u Chapter 7, Microsoft Money, OFC and Crash Recovery

This explains how Microsoft Money uses features in OFC to recover from communication and system errors.

u Chapter 8, OFC Data Format Details

This chapter provides more explanation of the OFC data format and introduces how Microsoft Money takes advantage of it.

u Chapter 9, OFC Aggregates and Elements

This explains each aggregate and element in the OFC data format.

u Chapter 10, OFC and Signon Records

This explains the OFC record and the Signon request and response.

u Chapter 11, Account Records

This explains the Account request and response records.

u Chapter 12, Mail Records

This explains the Mail request and response records.

u Chapter 13, Online Banking Records

This explains the records associated with online banking: Statement request and response, Interbank transfer request and response, Interbank transfer request and response

u Chapter 14, Online Bill Payment Records

This explains the records associated with online bill payment: Payee request and response, Payment request and response, Payment inquiry request and response.

u Chapter 15, File import records

This explains the structure for the Account Statement record.

Related Documentation

Additional documents related to OFC, Microsoft Money and online financial services can be found on the Microsoft web site at http://www.microsoft.com/industry/bank/online.htm.

Chapter 1

The Microsoft Money 5.0 will support the OFC data format for its online home banking and online bill payment features.

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.

HTTP

Microsoft Money will use the HTTP (Hypertext Transfer Protocol) protocol to transfer OFC files to an OFC server. HTTP is the same protocol that is used to run the Internet’s World Wide Web.

HTTP consists of requests and responses. Money will send an OFC request file in an HTTP POST request and will expect an HTTP response with an OFC response file.

HTTP POST

This section includes the HTTP headers that Money will be sending when it sends an HTTP POST command to the bank’s server.

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>

… data in the OFC file …

</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 response

This section describes the HTTP headers that Microsoft Money will expect when receiving data from a bank’s server.

HTTP 1.0 statuscode statusstring

Content-Type: application/x-ofc

Content-Length: length in bytes of OFC file

<OFC>

…data in the OFC file…

</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:

Statuscode	Statusstring	Explanation
200	OK	The server should return 200 OK if it was able to process the OFC data sent to it in the HTTP POST and produce a response.
400	Bad request	The server should return 400 Bad request if it is unable to process the OFC request file.
403	Access denied	The server should return 403 Access denied if security is enabled on the server but the client is attempting to connect without security. Money will always attempt to connect with security; this HTTP error should be implemented as a safeguard.
500	Server error	The server should return a status of 500 when the server is unavailable.

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.

Connectivity options

Microsoft Money supports two connectivity options between the client and a bank’s server: Internet and dial-up PPP. A bank must choose one connection method for its customers. Money will offer the same functionality with each connection option.

Internet

Microsoft Money can use the Internet to communicate with a bank’s server. Money will not supply Internet access for its users. A user must have an account with a Windows compatible Internet Service Provider (ISP). Money will use the user’s ISP to create an Internet connection and then use that connection to communicate with the bank’s server.

Implementing the Internet connection option

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

Private dial-up connection

Microsoft Money can connect to a bank’s server through a private dial-up network running the Point-to-Point protocol (PPP). In this case, the bank will provide the user with a telephone number to connect to their server.

Implementing the Private dial-up connection option

A bank should take the following steps when supporting a private dial-up connection:

Purchase a modem pool and PPP server. Money users will dial into a modem connected to the PPP server. Microsoft Money has been tested using the PPP server (called Remote Access Server) built into Windows NT Server.
Get a telephone number for the modems and PPP server. When connecting to the server, Money will dial this telephone number.
Perform all the steps listed in the section above called "Implementing the Internet connection option."
A PPP server should support the following PPP settings:

PPP setting	Explanation
IP header compression	Money will use IP header compression.
Software compression	Money will use the software compression supported by the PPP server.
Authentication protocols	Money will use the CHAP and SPAP authentication protocols. These will be used when the user connects and logs into the PPP server.
Network login	Money will not support a general network login. Money users will connect to the PPP server and will not be allowed to connect to other computers connected to the bank’s network.

Note: The URL for the HTTP server should include the server’s IP number rather than friendly name. For example "http://159.2.59.59/isapi.dll" refers to the server with IP number 159.2.59.59 on the network. The Internet uses a protcol called DNS to map IP numbers to friendly names. DNS is usually not available on private networks.

Mode of operation

Batch mode

Microsoft Money 5.0 operates in a batch mode. While off-line, a user will queue up transaction requests (requests for account information, requests to make bill payments, etc.)

When a user chooses to send these requests to their bank, Money will create a single OFC file containing the requests and will send that file to the bank’s server. While the user is online, the bank’s server will process the requests in that file and produce a single OFC file with the responses. The bank server will send this file back to Microsoft Money. When this file has been received, Money will close the communication session and report the results of the session to the user.

File import mode

Microsoft Money will also support file import mode. This mode is designed to allow a user to import transactions in an OFC file (*.ofc) into their Microsoft Money data file.

File import mode does not specify the method of communication between Money and a server; the OFC file could be delivered to the user via electronic mail, downloaded from the World Wide Web, or distributed on a floppy disk. For instance, if a bank’s World Wide Web site allowed users to view the account activity for a particular account, that web site could also allow the user to download an OFC file that represented those transactions. Launching the OFC file will reconcile the transactions in the file with those already entered in Microsoft Money.

Timeout values

Money uses the following timeout values. When these values expire, Money will display an error message to the user telling the user that their bank’s server is unavailable and suggesting that the user attempt to connect at a later time.

Connect (establishing an HTTP connection via the Internet)	2 minutes
Send (Money sending an OFC file to the server)	1 minute
Receive (Money waiting for a response file from the server)	2 minutes

Chapter 2

All connections between Microsoft Money and a server will be secured. This section explains how Microsoft Money will secure sessions with a server.

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.

Possible risks

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:

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

Microsoft Money solutions

Using features of OFC and standard, Internet security protocols and techniques, an OFC-based solution using Microsoft Money addresses these risks.

All connections (Internet and dial-up PPP) between Microsoft Money and a bank’s server will be secured using the SSL or PCT protocols. These sessions will be encrypted using 128 bit keys (64-bit internationally.) This will create a secure channel of communication between Money and a server.
Because Microsoft Money uses the HTTP protocol to transfer OFC files between client and server, a bank’s architecture using OFC can take advantage of "firewall" technology to isolate the computers on an internal network from the outside world. A firewall can be configured to only accept data of a particular type or from a particular client application. The flexibility of the OFC architecture based on standard protocols enables the bank to choose the firewall solution that meets their needs.
Setting up for online services with Microsoft Money and OFC uses the authentication policies established by the bank. Money’s online services setup process relies on the user contacting their bank and the bank issuing the user an identification code and password. The bank can define the policy detailing how to authenticate the user before enabling online services for that user.
Microsoft Money will only send OFC files to the server. No interpreted or compiled executable code will be sent from Money to the server. OFC files cannot include instructions to disrupt or harm the host system.
Microsoft Money will only accept valid OFC files received from the server. No binary data will be accepted. In addition, Microsoft Money does not use HTTP cookies that store information on the client machine without the user knowing about it.

Secure communication protocols

Microsoft Money will support two Internet standard protocols for securing the communication channel between client and server: Private Communications Technology (PCT) and Secure Sockets Layer (SSL). Money will support PCT 1.0, SSL 2.0 and SSL 3.0.

PCT and SSL also guarantee the integrity of messages sent between client and will authenticate the identity of a server using certificates. Money will support a 128-bit key (64-bit internationally) for use with SSL or PCT.

Note: Email ofc@microsoft.com for more information on enabling your server to use 64 bit encryption.
PCT and SSL

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.

Communicating over a private network

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.

OFC User ID and Password

To set up Microsoft Money for use with OFC, the user will be asked for a bank-issued user identification code and password.

The user identification code must uniquely identify a user (i.e. social security number) on the bank’s server. A user will enter their password into Microsoft Money once and it will be sent to the bank’s server in every session.

A user must enter their password before calling the bank’s server. Microsoft Money will never write this password to disk and will always be displayed as asterisks (*) in the Money user interface. A bank can send a request to Microsoft Money that will force the user to change their password on the next session.

Implementing security

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.

Note: The Common Name on the server’s certificate should be the URL of the server (servername.domainname) For example, www.bank.com is a valid Common Name. When connecting to a server, Money will match the Common Name on the certificate with the server’s URL. If they match, Money will allow the session to proceed. If they don’t match, Money will alert the user that the server they are connecting to may be an impostor. The user will be given the option to proceed or to cancel the session.

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.

Identifying a financial institution

The first step in Money’s online services setup process involves the user providing Money with the 9 digit routing and transit number or the first 6 digits of their credit card number.

This information will be sent to the Branding Server. The Server will match the routing and transit number or credit card number to a financial institution. Once the Branding Server has identified an institution, the information provided by the institution will be downloaded to Money.

Defining information for the Branding Server

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.

Branding Server provider information for OFC

Each bank who implements an online solution based on OFC will provide a data file in the following format to the Branding Server. These data files are text files and can be composed using Windows Notepad.

Note: Instructions detailing how to submit this information to the Branding Server will be posted on http://www.microsoft.com/industry/bank/online.htm. Or, contact ofc@microsoft.com for more information.

Line item name	Possible values	Details
[OFC]	N/A	This is a constant expected to be the first line of every data file.
Services=	0 - The server supports OFC online banking. 1 - The server supports OFC online bill payment. 0,1 - The server supports both OFC online banking and online bill payment. 0,2 - The server supports OFC online banking and bill payment (Int’l releases only.) 0,3 - The server supports OFC online banking and bill payment (Int’l releases only.) 0,4 - The server supports OFC online banking and bill payment (Int’l releases only.)	This value will enable the Microsoft Money user interface for online banking. This value will enable the Microsoft Money user interface for online bill payment This value will enable the Microsoft Money user interface for both services. This value will enable the Money user interface for both services. The user will be asked to supply a payee ID or the destination account information. This value will enable the Money user interface for both services. The user will be asked to supply a payee ID. This value will enable the Money user interface for both services. The user will be asked to supply destination account information.
DaysInquiryMax=	Any number (60 is the minimum required value.)	How many days into the future can the user inquire on an electronic bill payment after its due date.
DaysPreWithdrawalDefault=	Any number	Used for online bill payment services. Number of days lead time before withdrawal of money from user’s bank account.
DaysPostWithdrawalDefault=	Any number	Used for online bill payment services. Number of days after withdrawal of money from user’s bank account when check arrives at payee.
DaysIntraBankPreWithdrawalDefault=	Any number	If the bank processes INTRARQ transfers immediately, this should be zero (0.)
DaysIntraBankPostWithdrawalDefault=	Any number	If the bank processes INTRARQ transfers immediately, this should be zero (0.)
DaysInterBankPreWithdrawalDefault=	Any number	If the bank processes INTERRQ records immediately, this should be zero (0.)
DaysInterBankPreWithdrawalDefault=	Any number	If the bank processes INTERRQ transfers immediately, this should be zero (0.)
URL=	http://ofc.bank.com/isapi.dll	This is the URL for the bank’s OFC server.
Dialup=	0 - Internet 1- Private dial-up	"Internet" means that the bank’s server is accessible via the Internet and the user must use Money with an ISP to connect to the server. "Private dial-up" means that the bank’s server is accessible via a private dial-up network running the PPP protocol.
CountryID=	TAPI country ID	Needed if Dialup=1. This is the TAPI country ID used by Microsoft Money. The value for the United States is 1.
AreaCode=	The three digit area code of the server’s phone number.	The AreaCode= entry is needed only if Dialup=1.
Phone=	The phone number of the server.	If Dialup=1 and Phone= exists but is blank, Money will prompt the user for a phone number when the user configures Money for online services.
RASUserName=	The user name used to log the user into the PPP server.	This entry is only required if Dialup=1.
RASPassword=	The password used to authenticate the user into the PPP server.	This entry is only required if Dialup=1.
RASPhoneEntry=	Used by Money to name the Dial-Up Networking program used to connect to the PPP server.	This should be the name of the bank, ex. "First Bank."

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

Before a user can start using online banking and/or online bill payment with Microsoft Money, they must go through a setup process. Microsoft Money will include a wizard to walk the user through each step of the process.

This section of the specification describes each step of the setup wizard, highlighting the bank’s involvement in this process.

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.

Setting up for online services with Money

Step 1 - Enter RTN or BIN

The first step of setting up online services will involve a user entering in the routing and transit (RTN) or Bank Identification Number (BIN) for their bank. Users will be asked to enter the 9 digit routing and transit number found in the lower left-hand corner of their checks or the first 6 digits of their credit card.

Step 2 - Download info from Branding Server

Next, Money will call the Branding Server and ask it to download a profile of information about the bank. This includes details on how to connect to the bank’s server as well as logos and other information to customize the Money interface.

Step 3 - Enrolling for online services with the bank

The profile will include a description of the online services offered by the bank and instructions that a user should follow to become enrolled for online services.

For example, a bank may tell users to call a 1-800 number and speak with a customer service representative. Or, a bank may point users to their web site where a user can fill out a form and immediately get authorized for online services with Money.

Regardless of the means a bank uses to get a user set up for online services, a bank should provide a user with the following information:

A User ID. The user will be prompted for this in a dialog of the Money online setup wizard. The User ID should uniquely identify a user (e.g. social security number, account number.)
Note: This is the <USERID> element of the Signon request.
A user password. The user will be prompted for this each time they connect to the bank’s server.
Note: This is the <USERPASS> element of the Signon request.
(Optional) A phone number used to connect to the bank’s server. If the server is accessible via a private, dial up network, and the bank has not specified a phone number in the Phone= entry of the Branding Server Provider information for OFC (reference chapter 3) then Money will prompt the user to enter a phone number in a dialog of the Money online setup wizard.
A list of accounts enabled for online services. It’s assumed that the bank will enable particular accounts for online services. The bank should tell the user what accounts are enabled and what online services are enabled for those accounts.

For example, the bank should tell the user the following information about each account:

- The name of the account (Checking, Savings, Credit Card)

- The account number of the account.

- The online services enabled for the account (online banking, online bill payment, or both.)

Step 4 - Enabling Money accounts for online services

The final step in Money’s online setup wizard will involve the user enabling their Money accounts for online services. The user will be asked to choose an account they’ve set up in Money and choose the online services (online banking, online bill payment, or both) their bank has enabled for that account.

Chapter 5

Online bill payment is the service where users can send a payment to any payee using Microsoft Money. Online bill payment also includes the ability for users to inquire on the status of previously sent payments and cancel payments.

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.

Paying a bill in Microsoft Money

Microsoft Money accounts that are enabled for online bill payment will expose additional user interface to help a user denote a payment as one that should be sent using online bill payment.

Entering an electronic payment

Entering an electronic payment entails a user entering the due date of the payment they wish to be paid into the Microsoft Money Account Register. Based on the capabilities of the bill payment system (see the sections on Days-to-pay and Funds withdrawal date below), the Money account register will record the date the funds will be deducted from the user’s account.

Microsoft Money will allow users to schedule electronic payments up to one year into the future.

Validating the payment

If the user is entering a payment to a payee that the user has not paid previously, they will be asked to provide details to route the payment to the payee. This includes the payee’s street address, city, state, zip code, phone number and the user’s account number with that payee. If the user enters a payment to a payee that has been paid previously, Money will not prompt the user for this information.

Determining a valid payment date

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

Federal Reserve holiday schedule

Microsoft Money will validate payment dates to ensure users request payments on business days (Monday to Friday). And, Money also has knowledge of the Federal Reserve holiday schedule. If a user attempts to schedule a payment on one of these dates, the user will be asked to schedule the payment on the next business day after the holiday.

New Year’s Day	January 1
Martin Luther King Day	Third Monday in January
President’s Day	Third Monday in February
Memorial Day	Last Monday in May
Independence Day	July 4
Labor Day	First Monday in September
Columbus Day	Second Monday in October
Veterans Day	November 11
Thanksgiving Day	Fourth Thursday in November
Christmas Day	December 25

Days-to-pay value

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.

Reference the <DAYSREQD> element in the Signon response <SONRS> and Payee response <PAYEERS> records. The Signon response is described in the OFC and Signon Records chapter, the Payee response is described in the Online Bill Payment Records chapter.
Withdrawal date value

The withdrawal date value is the number of business days prior to the payment’s due date when the funds are deducted from the user’s bank account. Some payment systems that require guaranteed funds deduct funds from the user’s account before the due date, while others deduct funds from the user’s account on the date the payment is due.

A bill payment service’s default withdrawal date value will be downloaded from the Branding Server. Microsoft Money will record transactions in the account register according to when the funds are withdrawn from the user’s account. For example, if the user enters a payment with a due date of January 10^th and the bill payment service has a funds withdrawal date of four (4), the payment will be recorded in the user’s Money account register as occurring on January 6^th.

At any time, the server can send Money a new default funds withdrawn date value using the <DAYSWITH> element in the OFC Signon response.

This value can also be specified by the server for each payee the user has paid electronically. At any time, the server can send Money a new funds withdrawal date value for a particular payee using the <DAYSWITH> element in the OFC Payee response.

Reference the <DAYSWITH> element in the Signon response <SONRS> and Payee response <PAYEERS> records. The Signon response is described in the OFC and Signon Records chapter, the Payee response is described in the Online Bill Payment Records chapter.
Payee add behavior

The first time a user sends a payment to a payee, Money will send the OFC Payee request record (PAYEERQ) in addition to the OFC Payment request record (PAYMTRQ.) The Payee request record includes details about the payee so it can be added to the bill payment system.

The server will respond with a Payee response record. The bill payment service will assign a identification code to a payee and return it to Money in the <PAYEEID> element. If the server has returned a PAYEEID for a payee and the user sends subsequent payments to this payee, Money will send the PAYEEID and not the complete details (street address, city, state, zip code, account number) of the payee.

For more information, reference the <PAYEEID> element in the Payee response <PAYEERS> and Payment request <PAYMTRQ> records. The Payee response and Payment request are described in the Online Bill Payment Records chapter.

Inquiring about a payment

Using Microsoft Money, users will be able to inquire about the status of a previously sent payment. Inquiries are modeled after email; users can select a particular payment and type a question about it. This email will be sent as an OFC Payment Inquiry request to the server. The OFC Payment Inquiry request will include the payment’s confirmation number (SRVRTID) for easy reference by the bill payment processor.

For more information, reference the MAILRQ,, MAILRS and PAYIQRQ, PAYIQRS records in the Mail Records chapter and the Online Bill Payment records chapter.
Canceling a payment

Money users can sent requests to cancel a payment if the payment has not yet been processed. If today’s date + days-to-pay are less than the due date of the payment, Money will enable user interface that will allow the user to send a request to cancel a payment to the server.

Chapter 6

Online banking is the service where users can download their latest account balance, posted transactions and transfer money between accounts. Online banking also enables the user to send email to their bank.

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.

Matching downloaded transactions

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.

Transferring funds

Users can transfer funds to and from accounts that are enabled for online banking. Both accounts must be at the same bank. Money will not allow future-dated transfers.

Email

Users who have enabled online banking in Microsoft Money will be able to send messages to their bank.

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

On each session with the server, Money will put the date and time of the call in the DTCLIENT element of the Signon request.

If a communication error occurs during a session or if the connection encounters a "time-out," Microsoft Money will enter crash recovery mode. While in this mode, a user will not be confident if their transactions were received by the server or not.

While in crash recovery mode, Money will not permit the user to send new transactions to the server. The user will be prompted to call the server again and resend the previous set of transactions. Crash recovery mode persists between sessions with Money.

When the user calls the server again, Money will send the exact same OFC request file to the server as it did on the last call to the server, when Money encountered a crash. This file will have the DTCLIENT value of the previous session. Money assumes that the server didn’t receive the transactions and sends them again. If the transactions were received and processed by the server, it is the server’s responsibility to prevent the transactions from processed twice.

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

Algorithm to follow:

If (DTCLIENT in the current Signon request == DTCLIENT in the previous Signon request)

Don’t process the transactions in the request
Send the previous response file to Money

Else

Process the transactions in the request

Using the SESSKEY element to track sessions

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.

Algorithm to follow if the server is tracking SESSKEYs:

If (DTCLIENT in the current Signon request == DTCLIENT in the previous Signon request)

Don’t process the transactions in the request
Send the previous response file to Money

Else

If SESSKEY in the request file is the expected SESSKEY

Process the transactions in the request

Else

SESSKEY in the request file is not the expected SESSKEY and is not the previous SESSKEY

Don’t process the transactions in the request
Send just a Signon response with STATUS of 103

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.

Introduction to the OFC format

Syntax

OFC files use a syntax based on Standardized General Markup Language (SGML). Records and aggregates are marked using open and closing tags to denote the beginning and end of the record or element. Elements are marked in a similar fashion, using one tag. Data immediately follows the tag.

Structure

OFC files are composed of records, aggregates, and elements. Each OFC record can hold a series of elements and/or aggregates. Elements represent single pieces of data like a date or a password. Aggregates are collections of elements and are used to describe more complex structures like an account or a payee. For example:

</Aggregate>

</Record>

Order of records (batch mode)

Microsoft Money requires that records in a valid OFC file be in the following order:

Note: <OFC> and </OFC> tags must surround every OFC file.

Request file	Response file
<OFC>	<OFC>
*Signon records*
Signon request <SONRQ>	Signon response <SONRS>
*Maintenance records*
Account request <ACCTRQ>	Account response <ACCTRS>
Payee request <PAYEERQ>	Payee response <PAYEERS>
Mail request <MAILRQ>	Mail response <MAILRS>
*Transaction records*
Intrabank transfer request <INTRARQ>	Intrabank transfer response <INTRARS>
Interbank transfer request <INTERRQ>	Interbank transfer response <INTERRS>
Statement request <STMTRQ>	Statement response <STMTRS>
Payment request <PAYMTRQ>	Payment response <PAYMTRS>
Payment inquiry request <PAYIQRQ>	Payment inquiry response <PAYIQRS>
</OFC>	</OFC>

Notes:

OFC files must have Signon records, then Maintenance records and then Transaction records. Within each section, the individual records do not need to be in a particular order.

Identifiers

OFC uses three identifiers to uniquely identify transactions. This section describes the purpose of each identifier.

Identifier	Description
<CLTID>	Client identifier. This value is assigned by Money to uniquely identify a transaction. CLTIDs are found in every OFC record except the Signon request and Signon response. The server should always echo the CLTID value from the request in the response. CLTID is used to match OFC responses with OFC requests. CLTID can be up to 10 digits in length.
<SRVRTID>	Server transaction identifier. This value is assigned by a server to identify a transaction. For example, a confirmation number for a transaction is a SRVRTID. SRVRTID appear in the Money user interface as a "Confirmation #" for a payment. Money will display up to 8 characters for a Confirmation #. SRVRTIDs appear in STMTRS, INTRARS, INTERRS, PAYMTRS, PAYIQRQ, PAYIQRS, ACCTSTMT records.
<FITID>	Financial institution transaction identifier. This value is assigned by a financial institution to identify a transaction. FITIDs are included in STMTRS and ACCTSTMT records. Money uses FITIDs to prevent duplicate transactions when the user reconciles a downloaded bank statement. FITIDs appear in the STMTRS and ACCTSTMT records. It is strongly suggested that STMTRS and ACCTSTMT records include FITID elements for each transaction. FITIDs can be no longer than 255 characters.

Element lengths

The following table lists the field lengths imposed by Money 5.0 on some OFC elements. Maximum lengths are listed in the Length column.

Element	Length
<ACCTID> Account number	22 characters
<BANKID> Routing number	9 characters
<BRANCHID> Branch number	9 characters
<MEMO> Memo text	255 characters
<NAME> Payee name	32 characters
<ADDRESS> Address	32 characters
<CITY> City	20 characters
<ST> State	2 characters
<POSTALID> Zip code	9 characters
<PHONE> Phone number	10 characters
<PAYEEID> Payee identifier	32 characters
<PAYACCT> Account number with payee	32 characters
<USERID> User identifier	32 characters
<USERPASS> User password	32 characters
<SESSKEY> Session key	32 characters

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

Each OFC response includes an <ERROR> element to hold error messages produced by the server. If the STATUS element in an OFC response is 100, Microsoft Money will display the information in the <ERROR> element to the user in its Call Summary dialog box. If a request was rejected by the server, the <ERROR> element should inform the user why the request was rejected and instruct them how to remedy the situation.

Servers can include one <ERROR> element in each response record. Each <ERROR> can be up to 65,534 characters long.

Illegal characters

An OFC server should never include the greater than or less than characters (>, <) in the data of a response. This applies to all aggregates and elements. Money will be unable to read OFC files that contain these characters. For example, this is an illegal response:

<MEMO>This is > than that.

Record structure with error responses

OFC response records include the STATUS element that tells Money if the corresponding request record was accepted or not. STATUS != 0 tell Money that the server did not process the request record.

When returning a response with a STATUS != 0, the server should include an opening tag for the record, a CLTID, a STATUS, (an ERROR if the STATUS is 100) and a closing tag for the record.

For example:

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

Account <ACCTTO>, <ACCTFROM>

The account aggregate is used to describe an account.

Tag	Description
<BANKID>	Unique identifier for the bank (e.g. routing and transit number)
<BRANCHID>	Used to describe international banks.
<ACCTID>	Account number at bank
<ACCTTYPE>	Type of account (aggregate)

Account type <ACCTTYPE>

The account type aggregate provides a more detailed description of an account. Money uses it to match downloaded accounts with those created in Money.

Value	Description
0	Checking
1	Savings
2	Credit card
3	Money market
4	Line of credit
5	Loan (Not supported by Microsoft Money)
6	Interbank transfer payee
7	Other

Action <ACTION>

The action is used in transaction requests to instruct the server to do something on behalf of the user.

Value	Description
0	Add
1	Delete
2	Change

Amount <AMOUNT>

Amounts are composed of digits. A period "." or comma "," should be used to separate digits. If the amount is a debit, a minus "-" sign should be placed before the digits.

Amounts should always have 2 numbers following a decimal point.

<AMOUNT> XXXX.XX (credit w/ period)

<AMOUNT> XXXX,XX (credit w/ comma)

<AMOUNT>-XXXX.XX (debit w/ period)

<AMOUNT>-XXXX,XX (debit w/ comma)

Date and time <DTCLIENT>, <DTSERVER>

<DTCLIENT> and <DTSERVER> are used to specify date and time values. Both of these elements are based on the local time of the server and Money. The following syntax is supported

YYYYMMDDHHMMSS

YYYYMMDD (no time specified)

Online services <SERVICE>

SERVICE is used to define the online services supported by the server.

Value	Description
0	Online banking
1	Online bill payment
2	Interbank transfer (int’l.)
3	Interbank transfer (int’l.)
4	Interbank transfer (int’l.)

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)

Payee <PAYEE>

PAYEE is used to describe a payee (merchant or individual). A PAYEE can be anyone the user wishes to pay electronically.

Tag	Description
<NAME>	Name of payee
<ADDRESS>	First line of payee’s address
<ADDRESS>	Second line of payee’s address
<CITY>	Payee’s city
<STATE>	Payee’s state
<POSTALID>	Zip code
<PHONE>	Payee’s telephone number

Statement transactions <STMTTRN>

For each transaction downloaded in a STMTRS, a complete STMTTRN should be provided to describe the transaction.

Tag	Description
<TRNTYPE>	Type of transaction (aggregate)
<DTPOSTED>	Date transaction was posted to account
<TRNAMT>	Amount of transaction
<FITID>	Financial institution’s identifier for a statement transaction
<CLTID>	Money assigned transaction identifier
<SRVRTID>	Transaction identifier issued by the server
<CHKNUM>	Reference number for a transaction
<SIC>	Standard Industrial Code
<PAYEEID>	Payee identifier
<PAYEE>	Payee of transaction (aggregate)
<NAME>	Name of payee
<MEMO>	Description of transaction

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.

Value	Description
0	Accepted
1	Rejected
4	No CLTID (unsolicited transaction)
5	Bad SESSKEY (See chapter on Crash recovery)
100	Undefined error, include description in <ERROR> text
101	USERID not recognized
102	USERPASS not recognized
103	Password change requested
104	Account not recognized

Transaction type <TRNTYPE>

TRNTYPEs are used to define the type of a transaction.

Value	Description
0	Credit
1	Debit
2	Interest
3	Dividend
4	Service charge
5	Deposit
6	ATM withdrawal
7	Transfer
8	Check
9	Electronic payment
10	Cash withdrawal
11	Electronic payroll deposit
12	Other

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.

Tag	Description
<OFC>	Opening tag for the OFC record.
<DTD>	Version of the Document Type Definition used to parse this OFC file.
<CPAGE>	Code page of the server computer.
…OFC records…	Additional OFC records are inserted in between the <OFC> and </OFC> tags. Note: See Chapter 8 for the order of OFC records.
</OFC>	Closing tag for the OFC record.

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.

Tag	Description
<SONRQ>	Opening tag for the SONRQ record.
<SESSKEY>	Session identifier. Used to keep track of the session between client and server. Can be up to 32 characters in length.
<DTCLIENT>	Date and time of the client computer used for crash recovery
<USERID>	User identification on server. Money allows a USERID up to 32 characters in length.
<USERPASS>	User’s password on server. Money allows a USERPASS up to 32 characters in length.
<NEWPASS>	If the client allows the user to change their password, this field could hold the new password.
</SONRQ>	Closing tag for the SONRQ record.

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.

Tag	Description
<SONRS>	Opening tag for the SONRS record.
<STATUS>	Possible values here: Value Description 0 The transactions in the session were processed by the server. 5 The bank would like the user to change their password. 100 A general error from the server. 101 The USERID sent in the SONRQ is wrong. 102 The USERPASS sent in the SONRQ is wrong. 103 The SESSKEY is out of sequence.
<DTSERVER>	Date and time of the server.
<ERROR>	If the STATUS is 100, an explanation should be provided here.
<SESSKEY>	The SESSKEY for use in the next session.
<SERVICE>	Possible values here: Value Description 0 The server supports Online Banking 1 The server supports Online Bill Payment 2 The server supports Interbank transfers based on the user providing a Payee ID and destination account information. (Int’l releases only.) 3 The server supports Interbank transfers based on the user providing a Payee ID. (Int’l releases only.) 4 The server supports Interbank transfers based on the user providing destination account information. (Int’l releases only.) Note: If both services are supported, include two <SERVICE> elements.
<DAYSREQD>	The default days-to-pay value for a bill payment service.
<DAYSWITH>	The default funds withdrawn value for a bill payment service.
</SONRS>	Closing tag for the SONRS record.

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.