This specification describes the ofc data format and details how Microsoft ® Money uses ofc for online home banking and online bill payment features

OFC

Implementation details on

0. 
   When using OFC with Microsoft Money 5.0, the should be “2.”
   
1. 
   The value for should always be “1252.” This is the code page that should be used to interpret the character data following a tag.
   

Signon Request

Notes on

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

Signon Response

Notes on implementing :

0. 
   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.
   
1. 
   DAYSREQD updates the default days-to-pay value. The original default days-to-pay value is downloaded from the Branding Server.
   
2. 
   DAYSWITH updates the default withdrawal value. The original default withdrawal value is downloaded from the Branding Server.
   

If STATUS is 0

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

If STATUS is 5

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

If STATUS is 100

0. 
   A STATUS of 100 means that the server has returned a message for the user in the ERROR element.
   
1. 
   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.
   
2. 
   Include a date/time value of the server in the DTSERVER element.
   
3. 
   The server should include a message to the user in the ERROR element.
   
4. 
   The server should echo the value sent in the SESSKEY element of the Signon request.
   

If STATUS is 101

0. 
   STATUS of 101 means that the USERID sent in the Signon request was not valid.
   
1. 
   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.
   
2. 
   Include a date/time value of the server in the DTSERVER element.
   
3. 
   The server should echo the value sent in the SESSKEY element of the Signon request.
   

If STATUS is 102

0. 
   STATUS of 102 means that the USERPASS sent in the Signon request was not valid.
   
1. 
   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.
   
2. 
   Include a date/time value of the server in the DTSERVER element.
   
3. 
   The server should echo the value sent in the SESSKEY element of the Signon request.
   

If STATUS is 103

0. 
   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.
   
1. 
   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.
   
2. 
   Include a date/time value of the server in the DTSERVER element.
   
3. 
   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.
   
4. 
   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

0. 
   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:
   

If the password was not changed, return the following MEMO in the same record as above: