Open Financial Connectivity

Thaddeus Westhusing
Name of Company or Organization

Created: November 11, 1996
Revised:


Introduction

This document provides an overview of Open Financial Connectivity (OFC) and its implementation by Microsoft Money '97. Also provided in this document are links to more detailed specifications on the OFC data format.


What is OFC

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. Microsoft Money 97 (version 5.0) supports the OFC data format for its online home banking and online bill payment features.


How OFC Works

Microsoft designed OFC with input from financial institutions that wanted to deliver online banking services directly to their customers. With Microsoft Money 97, financial institutions now have the option to connect directly to customers via the OFC specification using either the Internet or a private dial-up connection. Money 97 implements the OFC specification by using standard Internet protocols (HTTP or TCP/IP) and standard Internet security protocols (PCT or SSL) to connect to the bank's server. Financial institutions that choose initially to make the connection via a private dial-up network can switch to the Internet connection easily at a later date.


Features of OFC

OFC offers the following high-level benefits:

  • OFC enables financial institutions and third-party processors to build their own direct connection to Microsoft Money and their customers using Internet technology.
  • OFC allows financial institutions to select the back-end architecture of their choice, whether in-house or on an outsourcing basis, and to decide which online services they will provide their customers.


Benefits of OFC

Institutions choosing to implement an OFC solution can realize the following benefits:

  • Financial institutions using an OFC-based home banking solution find it easier to offer online services to consumers because of more options to choose from and more control over their online strategies.
  • As more financial institutions go online using OFC, consumers will benefit because they will be more likely to find that the institution they currently do business with offers home banking.


OFC Specification

The details of the OFC format for Online Banking and Online Bill Payment are described in the "Microsoft Money and Open Financial Connectivity (OFC)" specification.

Click here to access version 1.0.6 of this specification:

Also included in this release are OFC files for a sample OFC session. These files are helpful for understanding the context of the OFC specification.

Click below to access these sample files.


Active Statement Technology and Microsoft Money 97

Microsoft Corporation

Created: November 7, 1996
Revised: November 7, 1996


What is Active Statement Technology?

Active Statement Technology refers to a mechanism that Financial Institutions may use to deliver transaction history (or statement data) from Internet banking websites to customers who are using Microsoft Money 97. Active Statements are delivered to the Money client via a file that is created using the OFC data format. The Active Statement file is typically delivered to the user via the banks web site.

Microsoft Money allows the user to read the Active Statement file that has been downloaded, reconciling each transaction and allowing the user to assign categories to each transaction as required. In some cases Money will also attempt to intelligently assign default categories to transactions (refer to description of SIC codes below).


Active Statement File Format

The Active Statement file is created using the OFC data format. The Active Statement file leverages the OFC File Import record definition called the Account Statement (ACCTSTMT) record. Refer to Chapter 15 of the "Open Financial Connectivity and Microsoft Money" specification, version 1.0.6, for complete details on the format of this record.

This record is comprised of the following elements:

  • OFC Elements common to all files created in the OFC Data Format including the Document Type Definition (DTD) of the OFC file.

Note Refer to Chapter 8 of the OFC specification; "OFC Data Format Details" for more information on the DTD version.

  • The OFC Account Aggregate which is used to describe the bank and the account ID that should be the recipient of the statement data in the user's Money file.

Note Refer to the definition of the ACCOUNT aggregate in Chapter 9.

  • The OFC Statement Response record which encapsulates the details of each statement transaction. The Ledger Balance for the account is also included in the Statement Response record.

Note Refer to Chapter 13 for the definition of the Statement Response record.

The following OFC elements are required within the Statement Response record for the definition of each statement transaction:

  • The name of the Payee for the transaction (NAME or PAYEE)
  • The date the transaction was posted (DTPOSTED)
  • The amount of the transaction (TRNAMT)
  • The type of the transaction (TRNTYPE).

The following OFC elements may optionally be included in the definition of each statement transaction.

  • The check number for the transaction (CHKNUM)
  • A Standard Industrial Code for the transaction (SIC). Refer to FAQ below for more information on SIC codes.
  • If the transaction is a funds transfer the transaction may include the Account identifier of account that received the funds (ACCTTO)
  • A memo description of the transaction (MEMO)
  • A unique identifier for the transaction called a Financial Institution ID (FITID). This identifier is used to uniquely identify the transaction in the user's Money file.

Note While the FITID element is optional in the format it is strongly recommended that this identifier be included for each transaction. Money uses this identifier to ensure that duplicate transactions are not entered into the user's account register in the event that the user may download the same statement transaction more than once.

Click here to view a sample Active Statement file:


Active Statement file format FAQ

This section contains some of the questions that are frequently asked about the OFC format of the Active Statement file.

  • Q: How are FITIDs assigned and how is this identifier used in Money?
  • A: The FITID stands for Financial Institution transaction identifier and is expected to be assigned by the Financial Institution to each statement detail item. Money stores this ID with the transaction when it is imported. On subsequent calls, if these transactions are imported again for some reason, Money will be able to ensure that duplicate transactions are not entered in the account register by associating the duplicate transactions with the FITID. For this reason, these IDs are very important as they ensure the users perception of accurate financial data.
  • Q: How are the SIC codes in the OFC specification used in Money?
  • A: Money uses SIC codes to determine default categories. If a SIC code has been included for a transaction in the STMTTRN record, Money will use the default category listed in the specification when presenting the user with the transaction during statement reconciliation. If a SIC code is not present in the STMTTRN record, Money will simply not offer a default category. If transactions have been previously downloaded for the same Payee and the user has already specified a category for the Payee, then the SIC code will be ignored.
  • Q: How is the TRNTYPE in the STMTTRN used by Money?
  • A: In Money 97, the TRNTYPE may be used to offer the user a default category during statement reconciliation. If the TRNTYPE is Transfer, Service Charge or Interest, Money will offer those as standard categories If transactions have been previously downloaded for the same Payee and the user has already specified a category for the Payee, then the TRNTYPE will be ignored.


Creating Active Statement Files

Institutions that wish to implement Active Statement Technology on their web sites have two choices when it comes to generating the OFC file; develop the code internally, or leverage Microsoft's publicly distributed Parse & Build code to generate the files.

Microsoft currently offers public Parse & Build code that may be used by Institutions implementing Active Statement Technology to generate the OFC file. This code is written in ANSI C and therefore available for use on a variety of platforms (Unix, etc.). Functions are defined within the P&B code that create the ACCTSTMT record format.

Note Refer to the document OFCPB.DOC in the download area for more information on using Microsoft's P&B code to generate the ACCTSTMT records.


Testing Active Statement Technology

Testing your Active Statement implementation will have three main focuses:

that the data in the Active Statement file accurately represents the statement transactions for the user's accounts.

The burden here is on the Financial Institution to validate that the correct data is being extracted and translated from the backend legacy system where the data is stored.

Ensuring that the Active Statement file is in the correct format so that it may be read correctly by the Money client.

If the data in the Active Statement file is not formatted according to the OFC specification the user's attempt to read the statement data will fail. Money is not forgiving in this regard, any problem with the format of the file will cause the entire file to be unreadable.

In order to help in this effort. Microsoft delivers a utility that may be used by testers to validate OFC files. This application is called OFCVALID and can be downloaded in the download area of the OFC web site.

Ensuring the best experience for your Active Statement users.

To validate the user experience the Money client should be used in testing as much as possible. The Money client contains strong algorithms for reconciling the users transactions in the Active Statement file, but these algorithms rely on the data that is in the file. Make sure your data is accurate and include FITIDs for each transaction!


OFC Parse and Build

Version 2 July 1996

Tim Harris
Derek Hazeur
Microsoft Corporation

Created: February 28, 1996
Revised: June 26, 1996


Introduction

This document describes the parse and build code for handling the Open Financial Connectivity (OFC) file format. The OFC file format is a standard SGML (Standard Generalized Markup Language) format defined by an SGML DTD. To read an OFC file one could use a standard SGML parser that reads in the DTD and the file or write a specific parser that handles only the OFC DTD. We chose to provide one implementation of the OFC specific parser written in ANSI C for portability that could be used by providers on various platforms.

Click here for the OFC Parse & Build code:


Table of Contents

OFC Parse and Build 1Overview

This document describes the parse and build code for handling the Open Financial Connectivity (OFC) file format. The OFC file format is a standard SGML (Standard Generalized Markup Language) format defined by an SGML DTD. To read an OFC file one could use a standard SGML parser that reads in the DTD and the file or write a specific parser that handles only the OFC DTD. We chose to provide one implementation of the OFC specific parser written in ANSI C for portability that could be used by providers on various platforms.

The code provided is complete parse and build code meaning it will fully handle both requests and responses. An OFC server should only have to handle parsing a request and building a response. We provide the code for parsing into a linked list of transaction structures and building from the same list of structures. The server side will use the parse and build code in the following manner:

The parser is a standard recursive descent parser that makes use of a token table for the rules of the DTD. This table describes the token tag, whether or not the tag is required and the data type of the data associated with that tag. There is an entry in the table for each tag, both begin and end tags.

The parser takes a pointer to an OFC file in memory and operates on it from there. We parse in memory because the lowest level the structure for a transaction or aggregate contains pointers to strings for the individual elements which are actually pointers into the OFC image in memory. In parsing, we thus, modify the OFC file image itself, replacing certain characters with NULL to create C character strings. Parsing in-situ like this allows us to save memory and time, otherwise we'd have to allocate space for each character string and copy it from the OFC data to the new storage.

The parser is also designed to work within a multithreaded environment so no global variables are used and the current token and state of the tokenizer are passed around in all functions. This is important in an environment like NT using the Internet Information Server because extensions to that server are multithreaded DLLs and need to be thread safe.

The parser only works on legal OFC files. Any time an unknown or out-of-order tag is encountered an OFC_ERROR error code is returned. In this version we do not make an attempt to recover from an invalid file error. If the server gets an OFC_ERROR back from parsing a request it should return an HTTP status of 400, Invalid Request. We assume that the driver will generate only valid OFC files and that any parse error encountered is due to transmission errors so returning an HTTP 400 from the server will cause Money to enter crash recovery and re-send the same request.

Memory errors could also be encountered, though unlikely. If the parse or build cannot allocate memory the function returns a NO_MEMORY. This error flags an Internal Server error and should return an HTTP status of 500 to inform the client of the error.

The transaction list built by Parse and read by Build is a simple list format of structures that match the OFC Transactions and Aggregates as defined in the DTD. The <ofcdtd.h> header file describes these in detail. There is a high level structure defined for the OFCDOC type and then a structure of OFC transactions (OFCTRN) that is the main node in the linked list. The OFCTRN structure contains the type of the transaction, a pointer to the transaction specific structure and a link to the next transaction in the list. A linked list of structures was used in place of a full parse tree for ease of traversal.

The linked list for a hypothetical OFC file looks something like:

The build routines do a 2-pass build. The first pass is a verification phase on the linked list which your bank specific code must build. This pass tries to insure proper ordering of transactions according to the DTD and that all required fields are filled in. This validation will not validate individual elements, for example, we won't validate that a date is "bad" which will be validated, hopefully, by your server and the XSOFC driver on the client side.

The second pass does the actual build of the OFC data into a memory buffer. The strings you pass in the structures are copied into a memory buffer with the proper tags around them. On build we only use tags when they are required by the DTD, all optional tags are left off to keep the data small for transfer over the phone connection.


Source Files

The following list describes the source files included and what functions are in the files. We are not supplying a generic makefile with the files, you can merge the files with your server side code or create a link library if you choose. Your server code will need to be sure to include the header files marked in bold below since these have the structure definitions and the API function prototypes in them.

File | Functions
ofcdtd.h | Header file which defines the DTD data types and structures used for the parse and build linked list. Server code should #include this file.
ofcparse.h | Header file which defines the parsing API. Server code should #include this file.
ofcbuild.h | Header file which defines the build API. Server code should #include this file.
pbtypes.h | Header file that defines the types used internally be parse & build routines.
parse.h | Header file with function prototypes for parse
build.h | Header file with function prototypes for build
validlst.h | Header file for validation of list
ofclink.h | Headre file for linked list functions
ofcparse.c | OFC Parse API functions
parse.c | High level parse code for OFCDOC and high-level transaction types
pbanking.c | Parse code for banking-specific transactions
ppayment.c | Parse code for payment-specific transactions
pelement.c | Parse code for handling OFC elements and reading data types
token.c | Low-level token read routines, token table
ofcbuild.c | OFC Build API functions
build.c | Build code
validlst.c | Validation of linked list code
ofclink.c | OFC linked list functions
readme.txt | Readme file

There are other .cpp files in the distribution which are an MFC test application that allows you to open a .ofc file, parse it, rebuild it and write out the output. This way the initial file and output file can be compared to check both parse and build. The test application requires Microsoft Visual C++ 4.0 to compile. These files are:

File | Function
PAppDlg.h | Header file for PAppDlg class
ParseApp.h | Header file for ParseApp class
StdAfx.h | Header file for STDAFX (Visual C++ MFC functions)
PAppDlg.cpp | Code for the PAppDlg class
ParseApp.cpp | Code for the ParseApp class
ParseApp.rc | Resources for the test app
ParseApp.ico | Icon for the test app
ParseApp.rc2 | Resourcs for the test app
ParseApp.mak | VC++ Makefile for test app
ParseApp.mdg | VC++ Project Workspace for test app
StdAfx.cpp | Code for STDAFX (Visual C++ MFC functions)


Coding Conventions

The source code is all written in ANSI C for maximum portability. All code is written using "Hungarian" variable and function names which is standard in Windows development but may not be too well known outside of Windows. In header files the Hungarian notation is noted for any data types that we define, for example, the OFC Transaction structure is typed as "OFCTRN" and the Hungarian for variables of this type would be "ofctrn".

Common Hungarian used within the code is:

Hungarian Tag | Used For
sz | Character string (char *)
p | Pointer, example pofctrn is a pointer to an OFCTRN structure
pv | Pointer to void, like pvTrn is generic pointer to a transaction structure
Rc | Return Code


Reference


OFC Parse Functions

OFC parse functions define a method for parsing OFC document instances. They utilize the data structures previously described.

There are five parse function prototypes:

  • OFC parse initialize - used it initialize the hash table for token lookup
  • OFC batch request function - used to parse HTTP request files
  • OFC batch response function - used to parse HTTP response files
  • OFC file import function - used to parse OFC statement download files
  • Parse cleanup function - used to free memory allocated by any of the above parsing functions

InitOFCParse()

void  InitOFCParse()

This function MUST be called before any other parse calls are made to initialize the token lookup table. For an OFC server this call should be made when the server application or DLL is first loaded.

RcParseOFCRequest()

int RcParseOFCRequest(
    void * pvRequest,
    int cbRequest,
    POFCDOC * ppofcdoc);

The first parameter must point to a block of memory containing the OFC request file to be parsed. This function will convert the OFC request file into a series of NULL terminated string buffers during the parsing process. The size of the memory block will not be altered during this process.

The second parameter indicates the count of bytes in the memory block pointed to by pvRequest.

The third parameter is a pointer to a POFCDOC. The function will allocate memory for an OFCDOC, and assign the pointer to the OFCDOC structure if the function succeeds. The OFCDOC will contain the linked list of OFC transactions found in the request file. The function will allocate memory for all of the required OFCTRN structures, and the corresponding OFC transaction and aggregate structures. All of the string buffer pointers (szFoo) contained in the OFC transaction structures will point into the memory block containing the converted OFC file (pvResquest).

The function will return one of the following:

Value | Meaning
ALL_OK | Successful
OFC_ERROR | Illegal OFC File
NO_MEMORY | A memory allocation failed
INVALID_DTD_VER | The DTD version of the file passed in doesn't match the parser
INVALID_CALL | An internal error, this should not occur after the Beta release.

The caller of this function must call CleanupOFCDOCParse() in order to free the OFCDOC and it's associated structures when they are no longer needed. After calling CleanupOFCDOCParse(), the caller will then be responsible for freeing the memory block pointed to by pvRequest.

RcParseOFCResponse()

int RcParseOFCResponse(
    void * pvResponse,
    int cbResponse,
    POFCDOC * ppofcdoc);

The first parameter must point to a block of memory containing the OFC response file to be parsed. This function will convert the OFC response file into a series of NULL terminated string buffers during the parsing process. The size of the memory block will not be altered during this process.

The second parameter indicates the count of bytes in the memory block pointed to by pvResponse.

The third parameter is a pointer to a POFCDOC. The function will allocate memory for an OFCDOC, and assign the pointer to the OFCDOC structure if the function succeeds. The OFCDOC will contain the linked list of OFC transactions found in the response file. The function will allocate memory for all of the required OFCTRN structures, and the corresponding OFC transaction and aggregate structures. All of the string buffer pointers (szFoo) contained in the OFC transaction structures will point into the memory block containing the converted OFC file (pvResponse).

The function will return one of the following:

Value | Meaning
ALL_OK | Successful
OFC_ERROR | Illegal OFC File
NO_MEMORY | A memory allocation failed
INVALID_DTD_VER | The DTD version of the file passed in doesn't match the parser
INVALID_CALL | An internal error, this should not occur after the Beta release.

The caller of this function must call CleanupOFCDOCParse() in order to free the OFCDOC and it's associated structures when they are no longer needed. After calling CleanupOFCDOCParse(), the caller will then be responsible for freeing the memory block pointed to by pvResponse.

RcParseOFCStatement()

int RcParseOFCStatement(
    void * pvStatment,
    int cbStatment,
    POFCDOC * ppofcdoc);

The first parameter must point to a block of memory containing the OFC statement file to be parsed. This function will convert the OFC statement file into a series of NULL terminated string buffers during the parsing process. The size of the memory block will not be altered during this process.

The second parameter indicates the count of bytes in the memory block pointed to by pvStatement.

The third parameter is a pointer to a POFCDOC. The function will allocate memory for an OFCDOC, and assign the pointer to the OFCDOC structure if the function succeeds. The OFCDOC will contain the linked list of OFC transactions found in the statement file. The function will allocate memory for all of the required OFCTRN structures, and the corresponding OFC transaction and aggregate structures. All of the string buffer pointers (szFoo) contained in the OFC transaction structures will point into the memory block containing the converted OFC file (pvStatement).

The function will return one of the following:

Value | Meaning
ALL_OK | Successful
OFC_ERROR | Illegal OFC File
NO_MEMORY | A memory allocation failed
INVALID_DTD_VER | The DTD version of the file passed in doesn't match the parser
INVALID_CALL | An internal error, this should not occur after the Beta release.

The caller of this function must call CleanupOFCDOCParse() in order to free the OFCDOC and it's associated structures when they are no longer needed. After calling CleanupOFCDOCParse(), the caller will then be responsible for freeing the memory block pointed to by pvStatement.

CleanupOFCDOCParse()

void CleanupOFCDOCParse(
    POFCDOC * ppofcdoc);

The first parameter is a pointer to a POFCDOC. This must point to the OFCDOC created as a result of calling one of the previous OFC parsing functions. This function will free all OFCDOC, OFCTRN, OFC transaction, and OFC aggregate structures created as a result of calling one of the parsing functions. The caller will be responsible for freeing the memory containing the converted OFC document instance.


OFC Build Functions

OFC build functions define a method for creating OFC document instances. They utilize the data structures previously described. The user's of these functions will be responsible for allocating and freeing all memory associated with the use of these functions. Their purpose is to guarantee the correct syntax of the resulting OFC document instance as opposed to creating the data structures and linked list of transactions.

There are three build function prototypes:

  • OFC batched request functions - used to create HTTP request files
  • OFC batched response functions - used to create HTTP response files
  • OFC file import functions - used to create OFC statement download files
  • Cleanup of OFC file memory

RcCreateOFCRequest()

int RcCreateOFCRequest(
    OFCDOC * pofcdoc,
    void ** ppvRequest,
    int * pcbRequest);

The first parameter must point to an OFCDOC structure containing the batch of transaction structures which are to be contained in the document instance being created. The first transaction structure must be a signon request (SONRQ) transaction structure. All maintenance transactions must follow the signon request. All financial transactions must be at the end of the linked list of transactions. If the signon transaction is missing, or the remaining transactions contained in the linked list are not in the required order, the function will fail.

The second parameter must be a valid pointer to a void pointer. If the function succeeds, this will contain a pointer to the block of memory allocated by the function. The memory will contain the resulting OFC document instance represented by the OFCDOC structure.

The third parameter must be a pointer to an integer value. If the function succeeds, this will contain the size of the memory allocated by the function.

The function will return one of the following:

Value | Meaning
ALL_OK | Successful
OFC_ERROR | Illegal OFC File
NO_MEMORY | A memory allocation failed
INVALID_CALL | An internal error, this should not occur after the Beta release.

RcCreateOFCResponse()

int RcCreateOFCResponse(
    OFCDOC * pofcdoc,
    void ** ppvResponse,
    int * pcbResponse);

The first parameter must point to an OFCDOC structure containing the batch of transaction structures which are to be contained in the document instance being created. The first transaction structure must be a signon response (SONRS) transaction structure. All maintenance transactions must follow the signon response. All financial transactions must be at the end of the linked list of transactions. If the signon transaction is missing, or the remaining transactions contained in the linked list are not in the required order, the function will fail.

The second parameter must be a valid pointer to a void pointer. If the function succeeds, this will contain a pointer to the block of memory allocated by the function. The memory will contain the resulting OFC document instance represented by the OFCDOC structure.

The third parameter must be a pointer to an integer value. If the function succeeds, this will contain the size of the memory allocated by the function.

The function will return one of the following:

Value | Meaning
ALL_OK | Successful
OFC_ERROR | Illegal OFC File
NO_MEMORY | A memory allocation failed
INVALID_CALL | An internal error, this should not occur after the Beta release.

RcCreateOFCStatement()

int RcCreateOFCStatement(
    OFCDOC * pofcdoc,
    void ** ppvStatement,
    int * pcbStatement);

The first parameter must point to an OFCDOC structure containing the statement download transaction structures which are to be contained in the document instance being built. If the transactions contained in the linked list contain anything other than ACCTSTMT transactions, the function will fail.

The second parameter must be a valid pointer to a void pointer. If the function succeeds, this will contain a pointer to the block of memory allocated by the function. The memory will contain the resulting OFC document instance represented by the OFCDOC structure.

The third parameter must be a pointer to an integer value. If the function succeeds, this will contain the size of the memory allocated by the function.

The function will return one of the following:

Value | Meaning
ALL_OK | Successful
OFC_ERROR | Illegal OFC File
NO_MEMORY | A memory allocation failed
INVALID_CALL | An internal error, this should not occur after the Beta release.

CleanupOFCFile()

void CleanupOFCFile(
void ** ppvOFCFile);

The first parameter is a pointer to the OFC file in memory. This must point to the memory created as a result of calling one of the previous OFC build functions. This function will free the memory used by the OFC data.


Pseudo Code Example Server

What follows is some pseudo code that shows a typical Parse and Build session for a server.

// includes for OFC
#include ofcdtd.h"
#include "ofcparse.h"
#include "ofcbuild.h"

// includes for bank side

// Load routine for handler
MyHandlerLoad()
{
    InitOFCParse();  // initialize the OFC Parser
}

// handler routine for an HTTP Request
MyOFCHandler()
{
void     *    pOFCReq;
void  *    pOFCResp;
int        cbOFCReqLen;
int        cbOFCRespLen;
OFCDOC *     pofcdoc;
int        rcReturn;

// get the OFC data from the HTTP Request coming in
// and find the length of it from the HTTP headers
// TODO: Use your internet server functions here to
//       handle this
if (InternetReadHeader(CONTENT_TYPE) != "application/x-ofc")
{
    // handle error
}
cbOFCReqLen = InternetReadHeader(CONTENT_LENGTH);

// grab a buffer for the OFC data
pOFCReq = malloc(cbOFCLen);

// now read the data from the HTTP req into your buffer
InternetRead(pOFCReq, cbOFCReqLen);

// parse that data using the OFC Parse API
rcReturn = RcParseOFCRequest(pOFCReq, cbOFCReqLen, &pofcdoc);
if (rcReturn != ALL_OK)
{
    // handle the error
}

// TODO: now go track through the list pointed to by pofcdoc
// and generate your bank requests

// cleanup the list and delete your buffer
CleanupOFCDOCParse(pofcdoc);
free(pOFCReq);

// TODO: send data to the bank server

// TODO: get back list of response from bank, turn it into a
// linked list of response transactions

// now create the OFC Data
rcReturn = RcCreateOFCResponse(pofcdoc, &pOFCResp,
                     &cbOFCRespLen);

is (rcReturn != ALL_OK)
{
    // deal with error
}

// clean up your list
CleanupOFCDOCParse(pofcdoc);

// now generate an HTTP Response with the data using
// your Internet server functions
InternetSetHeader(CONTENT_LENGTH, cbOFCRespLen);
InternetSetHeader(CONTENT_TYPE, "application/x-ofc");
InternetSetContent(pOFCResp);

// free up the Response memory
CleanupOFCFile(pofcResp);

} // MyOFCHandler()


Microsoft's OFC Server Certification

Microsoft's
OFC Server Certification

Mark Hanson

Microsoft Corporation

Created: August 29, 1996
Revised: September 5, 1996


Introduction

Our intention with this document and the contents of the companion disk is to provide you with tools and information that will help in the development, testing and certification of your OFC server. We are providing a set of tests in that will allow us to certify your OFC server.

The certification tests that we will provide will not encompass the idiosyncratic behavior of your OFC server and customers. You will be required to test this behavior and help to ensure the goals of developing an OFC server.

Click here to access the sample files and utilities referenced in this article:


Table of Contents

I. Introduction 3Test Tool Contents


\DRIVER

This is the directory that contains the executable, dynamic link libraries for certifying an OFC Server. The directory contains:

Filename | Description
BOL.DLL | Bank Online DLL
DRIVER.EXE | Driver for executing the tests
POL.DLL | Pay Online DLL
INTER.DLL | Interbank Transfer DLL
DRIVER.REG | Registry settings for the driver
OFCCERT.INI | INI file for the driver

Details for setup of the driver in the Server Certification Setup section.


\DLLS

We have compiled several different versions of the XSOFC DLL that write the OFC request and response to disk. There are 2 steps required to use the these versions of the DLL.

  1. Create a C:\TEMP directory.
  2. Copy the appropriate version of the XSOFC.DLL over the one that Money installs.

We have included several different versions of the DLLs

Directory | Purpose
SECURE | 1. Security enabled 2. Payment method - Payee
SECURE_UK | 1. Security enabled 2. Payment method - Interbank
NOSECURE | 1. Security disabled 2. Payment method - Payee
NOSECURE_UK | 1. Security disabled 2. Payment method - Interbank

After you complete your call to your OFC server you will find REQUEST.TXT and RESPONSE.TXT in the C:\TEMP directory you created.


\REG

In this directory are 2 registry files. REALBDS.REG contains the settings pthat Money's setup program writes to the registry. BETABDS.REG contains the modified settings to utilize a different branding server from the production server. We encourage you to utilize the beta BDS.


\SAMPFILE

This directory contains the sample files that can be used via Money or the OFC test application. In order to use a particular file in conjunction with Money, add the following key to the registry:

RequestFile

The value of the key is the complete path and filename of the OFC request file. Example:

    c:\ofccert\sampfile\sonrq\sonrq1.ofc

Of course you can create new OFC requests or modify the files we have provided, but in order to use this testing hook, it must have the filename extension OFC. The location for the RequestFile key is:

HKLM\SOFTWARE\Microsoft\FASTXS\1.1\Providers\OFC

We have included sample files for the following: SONRQ, ACCTRQ, MAILRQ, STMTRQ, INTRARQ, INTERRQ, PAYEERQ, PAYMTRQ, and PAYIQRQ.


\TOOLS\PARSEAPP

This application, PARSEAPP.EXE uses the OFC parse and build code to validate the OFC files generated by Money and your OFC server as well as by hand. The application parses, builds, and validates the parse/build, this will help to ensure that the OFC requests, responses, or account statements generated are valid against the DTD.


\TOOLS\TESTAPP

The application OFCTEST.EXE is an application that will allow you to send OFC requests without using Money and view the response include HTTP status codes. This application will be most helpful early in the development lifecycle. While this tool can be used during the entire development phase, you should be sure to use Money to uncover problems in areas like crash recovery, statement download, and general interopertability.


\DOCS

This directory contains:

Filename | Description
OFCCERT.DOC | This document
OFCTEST.PPT | PowerPoint Presentation from OFC Developer's conference
INDEX.DOC | Lists and describes the Sample OFC requests that can be used with OFCTEST.EXE
OFC.DTD | The 2nd version of the DTD
OUTLINE.DOC | Testing Outline


Server Certification


How Server Certification Works

We have tried to make server certification as straight forward as possible, but in order to be flexible our certification requires a couple of steps.

  • Setup and Execution of the Test DLLs for your respective components. A complete list is at the end of this document.
  • Execution and documentation of the results from running manual tests via Money97.
  • Inspecting OFC code for specification implementation issues.
  • Sending the OFC files created when running the automated tests in step 1 back to Microsoft.
  • Fixing and resolving any problems that are uncovered.


Setup

In order to run the test driver it needs to be configured and setup the following list must be completed for the tests to run properly.

md c:\ofccert

md c:\ofccert\data

md c:\ofccert\driver

Copy BOL.DLL, DRIVER.EXE, DRIVER.REG, INTER.DLL, and POL.DLL to c:\ofccert\driver

Copy OFCCERT.INI to your windows directory

Load OFCCERT.INI into notepad and modify all the settings for your installation and save the file

Create a shortcut for DRIVER.EXE

Execute DRIVER.REG

Assumptions: We assume that you have the necessary communications setup in order to complete a call to your server. You might want to setup Money97 to verify this. We also expect that your server is setup with accounts that have the ability to perform the BOL, Interbank Transfer, and/or POL functionality.


Execution

After launching the DRIVER.EXE program, choose "Load Test DLLs…" and load the necessary DLL. Select all the tests and choose "Execute". After all the tests have completed and passed, choose "Save" and save the contents to the c:\ofccert\data directory with a unique name. If any of the tests fail, you should investigate why the test fails and fix the problem. If the reason the test fails is due to a provider specific implementation decision, make a note of these and send those back to us also. We expect that you will need to run and re-run the suite of tests several times to flush out issues.


Applying for Certification

The request and responses files for each automated test are stored in "C:\OFCCERT\DATA". After the full suite of tests are completed and succeed, copy the entire contents of this directory on a disk(s) along with the log files, and send them back to us. We will review the contents and results in thes files and notify you with the results.


Manual Crash Recovery Tests

All tests should be completed with SESSKEY = 0 and SESSKEY != 0.


DTCLIENT Algorithm

DTCLIENT = DTCLIENT previous call

STEPS:

  1. Create a new Money file in your c:\temp directory called, CRA1A.MNY
  2. Create Accounts (Checking, Savings, and/or Credit Card)
  3. In the Bank Place select the Accounts tab and choose the "Select online services…" button
  4. Online enable the account(s) for POL, BOL or both according to your server specific information
  5. On the Connect Tab in the Bank Place - Press connect
  6. When the Call Summary is displayed press (CTRL+ALT+DEL) - select "End Task" for Money's process.
  7. copy the following files from c:\temp to your c:\ofccert\data directory

· CRA1A.OFD (Do Not Delete)

· CRA1A.OFE (Do Not Delete)

· request.txt rename to CRA1ARQ.OFC

· if response.txt exists rename to CRA1ARS.OFC

  1. Delete the response.txt and request.txt files from your c:\temp directory
  2. Open Money and salvage the file
  3. Go to the Bank Place and press connect again
  4. This time press the continue button on the "Call Summary" dialog
  5. Copy the following files from c:\temp to your c:\ofccert\data directory

· request.txt rename to CRA1BRQ.OFC

· if response.txt exists rename to CRA1BRS.OFC

  1. Delete the response.txt and request.txt files from your c:\temp directory

DTCLIENT < DTCLIENT previous call

STEPS:

  1. Create a new Money file in your c:\temp directory called, CRA2A.MNY
  2. Create Accounts (Checking, Savings, and/or Credit Card)
  3. In the Bank Place select the Accounts tab and choose the "Select online services…" button
  4. Online enable the account(s) for POL, BOL or both according to your server specific information
  5. On the Connect Tab in the Bank Place - Press connect
  6. Continue at the "Call Summary" dialog
  7. copy the following files from c:\temp to your c:\ofccert\data directory

· request.txt rename to CRA2ARQ.OFC

· if response.txt exists rename to CRA2ARS.OFC

  1. Close Money
  2. Delete the response.txt and request.txt files from your c:\temp directory
  3. Open your system clock and change the date to "yesterday's date"
  4. Open Money
  5. Go to the Bank Place and press connect again
  6. Continue at the "Call Summary" dialog
  7. Copy the following files from c:\temp to your c:\ofccert\data directory

· request.txt rename to CRA2BRQ.OFC

· if response.txt exists rename to CRA2BRS.OFC

  1. Delete the response.txt and request.txt files from your c:\temp directory

DTCLIENT > DTCLIENT previous call

STEPS:

  1. Create a new Money file in your c:\temp directory called, CRA3A.MNY
  2. Create Accounts (Checking, Savings, and/or Credit Card)
  3. In the Bank Place select the Accounts tab and choose the "Select online services…" button
  4. Online enable the account(s) for POL, BOL or both according to your server specific information
  5. On the Connect Tab in the Bank Place - Press connect
  6. Continue at the "Call Summary" dialog
  7. Copy the following files from c:\temp to your c:\ofccert\data directory

· request.txt rename to CRA3ARQ.OFC

· if response.txt exists rename to CRA3ARS.OFC

  1. Close Money
  2. Delete the response.txt and request.txt files from your c:\temp directory
  3. Open Money
  4. Go to the Bank Place and press connect again
  5. Continue at the "Call Summary" dialog
  6. Copy the following files from c:\temp to your c:\ofccert\data directory

· request.txt rename to CRA3BRQ.OFC

· if response.txt exists rename to CRA3BRS.OFC

  1. Delete the response.txt and request.txt files from your c:\temp directory

DTCLIENT > DTCLIENT previous and SESSKEY = 0 (new file)

STEPS:

  1. Create a new Money file in your c:\temp directory called, CRA4A.MNY
  2. Create Accounts (Checking, Savings, and/or Credit Card)
  3. In the Bank Place select the Accounts tab and choose the "Select online services…" button
  4. Online enable the account(s) for POL, BOL or both according to your server information
  5. On the Connect Tab in the Bank Place - Press connect
  6. Continue at the "Call Summary" dialog
  7. copy the following files from c:\temp to your c:\ofccert\data directory

· request.txt rename to CRA4ARQ.OFC

· if response.txt exists rename to CRA4ARS.OFC

  1. Delete the response.txt and request.txt files from your c:\temp directory
  2. Create a NEW Money file with the same characteristics and user information as CRA4A.MNY but call it CRA4B.MNY
  3. Go to the Bank Place and press connect
  4. Continue at the "Call Summary" dialog
  5. copy the following files from c:\temp to your c:\ofccert\data directory

· request.txt rename to CRA4BRQ.OFC

· if response.txt exists rename to CRA4BRS.OFC

  1. Delete the response.txt and request.txt files from your c:\temp directory


SERVER does not respond in time

STEPS:

  1. Note: For this test the server will have to force a "time-out" response.
  2. Create a new Money file in your c:\temp directory called CRA5A.MNY
  3. Create Accounts (Checking, Savings, and/or Credit Card)
  4. In the Bank Place select the Accounts tab and choose the "Select online services…" button
  5. Online enable the account(s) for POL, BOL or both according to your server specific information
  6. On the Connect Tab in the Bank Place - Press connect
  7. After the Money client has connected to the server, the server should post a "time-out" response
  8. Verify that Money enters a state of Crash Recovery after receiving the "time-out" response
  9. Copy the following files from c:\temp to your c:\ofccert\data directory

· request.txt rename to CRA5ARQ.OFC

· if response.txt exists rename to CRA5ARS.OFC


Testing Checklist

BOL | POL | Manual | Test | Description
 |  |  | I. Accounts |
 |  |  | A. Enable |
X |  |  | 1. Single account BOL | Generates a SONRQ and an MAINTRQ for a single service, BOL.
X |  |  | 2. Multiple accounts | Generates a SONRQ and an MAINTRQ for 2 Accounts Account 1: BOL & POL Account 2: BOL
X | X |  | 3. Invalid accounts | Generates a SONRQ and an MAINTRQ for a single BOL account. The invalid account number is "777 777 7"
X | X |  | 4. Invalid account type | Generates a SONRQ and an MAINTRQ for a BOL account.The invalid account type is "77"
X | X |  | 5. Valid account incorrect user information | Generates a SONRQ and an MAINTRQ for a BOL account. Valid account information, invalid user info.
X |  |  | 6. First account invalid, second account valid | Generates a SONRQ and an MAINTRQ for 2 accounts. The data for the first account is invalid, and the second account is valid.
 | X |  | 7. Single account POL | Generates a SONRQ and an MAINTRQ for a single service, POL.
 |  |  | B. Disable |
X | X |  | 1. Single account | Generates a SONRQ and an MAINTRQ for turning off a BOL account.
X |  |  | 2. Multiple accounts | Generates a SONRQ and an MAINTRQ for turning off 2 accounts.
X | X |  | 3. Invalid account | Generates a SONRQ and an MAINTRQ for turning off 1 account. Invalid account number.
X | X |  | 4. Invalid account type | Generates a SONRQ and an MAINTRQ for turning off 1 account. Invalid account type.
X | X |  | 5. Valid account incorrect user information | Generates a SONRQ and an MAINTRQ for turning off 1 account. Invalid user information.
X |  |  | 6. First account invalid, second account valid | Generates a SONRQ and an MAINTRQ for turning off 2 accounts. First account invalid, second account valid.
 |  |  | C. Change |
X | X |  | 1. Single account | Generates a SONRQ and an MAINTRQ for changing the services for 1 account
X |  |  | 2. Multiple account | Generates a SONRQ and an MAINTRQ for changing the services for 2 accounts
X | X |  | 3. Invalid account | Generates a SONRQ and an MAINTRQ for changing the services for an invalid account
X |  |  | 4. First account invalid, second account valid | Generates a SONRQ and an MAINTRQ for changing the services for 2 accounts the first account is invalid and the second is valid.
 |  |  | D. Rejecting accounts |
X | X |  | 1. Server unavailable, HTTP Status = 500 | Checks for an HTTP status code of 500
X | X |  | 2. Attempt to connect w/o Security on Client, HTTP Status = 403 | Checks to make sure that security is enabled.
 |  |  | E. Change Password |
X | X |  | 1. All alpha | Change Password, all alpha characters.
X | X |  | 2. All numeric | Change Password, all numeric characters.
X | X |  | 3. Extended characters | Change Password, all extended characters.
X | X |  | 4. Alpha-numeric | Change Password, alpha-numeric characters.
X | X |  | 5. Maximum number of characters | Change Password, maximum number of characters.
X | X |  | 6. Mixed case | Change Password, mixed case characters.
X | X |  | 7. Minimum number of characters | Change Password, minimum number of characters.
 |  |  | F. Services |
X | X |  | 1. Invalid Service | Maintenance request contains invalid service.
X |  |  | 2. First service invalid, second service valid | Maintenance request contains invalid service for first account, valid service for invalid account.
 |  |  | G. General |
X | X |  | 1. Invalid OFC request, HTTP Status = 400 | Invalid OFC request, HTTPStatus = 400
 |  | X | 2. Account number formats * |
 |  | X | 3. Utilize account type * |
 |  | X | 4. Utilize SIC when possible * |
 |  | X | 5. Handle server errors * |
X | X |  | 6. Crash Recovery |
X | X |  | 7. Crash Recovery |
X | X |  | 8. Crash Recovery |
X | X |  | 9. Crash Recovery |
X | X |  | 10. Crash Recovery |
X | X |  | 11. Crash Recovery |
 |  |  | II. Statements |
 |  |  | A. Dates |
X | n/a |  | 1. Start < End | Base case, obtain a statement for the last 30 days.
X | n/a |  | 2. Start = End | Obtain a statement when DTSTART = DTEND
X | n/a |  | 3. Start > End | Obtain a statement when DTSTART > DTEND
X | n/a |  | 4. End > Current Date | Obtain a statement when DTEND > current date.
X | n/a |  | 5. Start -1 year | Obtain a statement when DTSTART is current date -1 year.
X | n/a |  | 6. Start -1 day | Obtain a statement when DTSTART is current date -1 day.
 |  |  | B. Account |
X | n/a |  | 1. Invalid Account number | Obtain a statement with an invalid account number
X | n/a |  | 2. Invalid Account type | Obtain a statement with an invalid account type
X | n/a |  | 3. Invalid Action | Obtain a statement with an invalid action, 7
X | n/a |  | 4. Delete Action | Obtain a statement with ACTION = 1
X | n/a |  | 5. Change Action | Obtain a statement with ACTION = 2
X | n/a |  | 6. Maintenace Request Fails, valid STMTRQ | Obtain a statement with an invalid MAINRQ, but the STMTRQ is valid.
 |  |  | C. Transactions |
 |  |  | 1. Withdrawals* |
 |  | X | a) Amounts should be negative |
 |  | X | b) Valid transaction type used |
 |  |  | 2. Deposits* |
 |  | X | a) Amounts should be positive |
 |  | X | b) Valid transaction type used |
 |  |  | D. General |
 |  | X | 1. Payee name returned if possible * |
 |  | X | 2. Check number returned if possible * |
 |  | X | 3. No < or > returned * |
 |  | X | 4. Accuracy of Ledger balance, all transactions posted* |
 |  | X | 5. Return FITID * |
 |  | X | 6. Multiple downloads per day* |
 |  | X | E. Limits |
 |  |  | III. Intrabank Transfers |
 |  |  | A. General |
X | n/a |  | 1. Transfer Checking -> Savings | Base case, transfer Checking -> Savings.
X | n/a |  | 2. Action = 1 | Transfer Checking -> Savings, ACTION = 1
X | n/a |  | 3. Action = 2 | Transfer Checking -> Savings, ACTION = 2
X | n/a |  | 4. Action = 77 | Transfer Checking -> Savings, ACTION = 77
X | n/a |  | 5. Invalid AccountFrom | Transfer Checking -> Savings, invalid ACCTFROM
X | n/a |  | 6. Invalid AccountTo | Transfer Checking -> Savings, invalid ACCTTO
X | n/a |  | 7. AccountTo and AccountFrom are the same | Transfer Checking -> Savings, ACCTFROM and ACCTTO are the same.
X | n/a |  | 8. Disable AccountFrom for BOL, send XFer | Transfer Checking -> Savings. ACCTFROM is disabled for BOL.
X | n/a |  | 9. Disable AccountTo for BOL, send XFer | Transfer Checking -> Savings. ACCTTO is disabled for BOL.
X | n/a |  | 10. AccountTo and AccountFrom are valid but different accounts | Transfer Checking -> Savings. ACCTFROM and ACCTTO are valid, but for different users
X | n/a |  | 11. Transfer Savings -> Checking | Transfer Savings -> Checking
X | n/a |  | 12. BankIDs do not match | Transfer Checking -> Savings. BANKIDS do not match
X | n/a |  | 13. Huge Amount (insufficient funds) | Transfer Checking -> Savings. TRNAMT = 999999.99
X | n/a |  | 14. Negative Amount | Transfer Checking -> Savings. TRNAMT = -3.14
X | n/a |  | 15. Set DTCLIENT back 30 days | Transfer Checking -> Savings. DTCLIENT is 30 days past.
X | n/a |  | 16. BankIDs are different between ACCTTO and ACCTFROM | Transfer Checking -> Savings. ACCTFROM bankid is invalid.
 |  | X | 17. Transfers when server is unavailable * |
 |  | X | 18. Transfers on holidays * |
 |  | X | 19. Limits * |
 |  |  | IV. Mail |
X |  |  | A. General | Standard MAILRQ, ACTION = 0.
X |  |  | 1. Action 0 | Standard MAILRQ, ACTION = 1.
X | X |  | 2. Action 1 | Standard MAILRQ, ACTION = 1.
X |  |  | 3. Action 2 | Standard MAILRQ, ACTION = 77.
X | X |  | 4. Action 77 | Standard MAILRQ, SERVICE = 1.
X | X |  | 5. Service 1 | Standard MAILRQ, SERVICE = 77.
X |  |  | 6. Service 77 | MAILRQ is missing ACCTFROM. ACCTFROM is necessary.
X |  |  | 7. No AccountFrom, and is needed | MAILRQ contains an invalid ACCTFROM and is necessary
X |  |  | 8. Invalid AccountFrom, and is needed | Standard MAILRQ, 18 lines by 60 characters
X |  |  | 9. 18 Lines x 60 characters | Non-standard MAILRQ, 18 lines by 61 characters
X |  |  | 10. 18 Lines x 61 characters | Non-standard MAILRQ, 19 lines by 60 characters
X | X |  | 11. 19 Lines x 60 characters | ACCTFROM is different than SONRQ
X |  |  | 12. AccountFrom is different than signon info | Non-standard MAILRQ, missing MEMO
X |  |  | 13. No memo | Non-standard MAILRQ, SERVICE = 1, and ACCTFROM is present.
 |  | X | 14. Service =1, and ACCTFROM |
 |  | X | 15. No < or > returned * |
 |  |  | 16. Limits * |
 |  |  | V. Pay Online |
 |  |  | A. Checking Payments |
n/a | X |  | 1. SESSKEY = 0 | First call
n/a | X |  | 2. SESSKEY != 0 | Not first call
n/a | X |  | 3. Pay any PAYEE | Capable of paying anyone
n/a | X |  | 4. BOL only account | Placed from a Bank Online only account
n/a | X |  | 5. Payment while disabling POL | Turning off Pay Online while making a payment
n/a | X |  | 6. BOL only account | Placed from a BOL only account but a second account is POL enabled
n/a | X |  | 7. DTDUE = earliest date possible | Payment made as soon as possible
n/a | X |  | 8. DTDUE = yesterday | Invalid payment date (date too soon)
n/a | X |  | 9. DTDUE = 1 year and 3 days in the future | Invalid payment date (date too future)
n/a | X |  | 10. DTDUE = a weekend | Invalid payment date (date is on a weekend)
n/a | X |  | 11. Valid PAYEEID | Payment made to the PAYEEID supplied by the server
n/a | X |  | 12. Invalid PAYEEID | Payment to a PAYEEID not on the server
n/a | X |  | 13. Multiple Payments (PAYEE) | Multiple payments to the same PAYEE for the same amounts on the same dates.
n/a | X |  | 14. Multiple Payments (PAYEEID) | Multiple payments to the same PAYEEID for the same amounts on the same dates.
n/a | X |  | 15. Optional MEMO | Payment with MEMO included
n/a | X |  | 16. ACTION = 2 | Standard PAYMTRQ, ACTION = 2
n/a | X |  | 17. ACTION = 10 | Standard PAYMTRQ, ACTION = 10
n/a | X |  | 18. DTDUE = 1 year ago | Invalid payment date (date too soon)
n/a | X |  | 19. Invalid SONRQ | Standard PAYMTRQ, placed with an invalid SONRQ
n/a | X |  | 20. Invalid BANKID | Non-standard PAYMTRQ, invalid BANKID
n/a | X |  | 21. TRNAMT is negative | Non-standard PAYMTRQ, the TRNAMT is a positive value
n/a |  | X | 22. DTDUE on a holiday* |
n/a |  | X | 23. Payment Limits* |
 |  |  | B. Cancel Checking Payments |
n/a | X |  | 1.Valid Cancellation |
n/a | X |  | a). Create a payment (PAYEE) | Payment DTDUE = Today + DaysToPay + 3 days
n/a | X |  | b). Cancel the payment | Standard PAYMTRQ to cancel
n/a | X |  | 2. Invalid Cancellation |
n/a | X |  | a). Create a payment (PAYEE) | Payment DTDUE = Today + DaysToPay (ASAP)
n/a | X |  | b). Cancel the payment | PAYMTRQ cancellation is invalid for payments made as soon as possible
n/a | X |  | 3. Valid Cancellation |
n/a | X |  | a). Create a payment (PAYEEID) | Payment made with PAYEEID, DTDUE = Today + DaysToPay + 3 days
n/a | X |  | b). Cancel the payment | Standard PAYMTRQ to cancel
n/a | X |  | c). Create the payment again | Verify that user is able to create the payment to that PAYEEID again
n/a | X |  | 4. Invalid SRVRTID |
n/a | X |  | a). Create a payment |
n/a | X |  | b). Cancel the payment | PAYMTRQ is made with an invalid SRVRTID
n/a | X |  | 5. Invalid payment information |
n/a | X |  | a). Create a payment |
n/a | X |  | b). Cancel the payment | Non-standard PAYMTRQ, the SRVRTID is valid, but the payment information does not match the original payment
 |  |  | C. Savings Payments |
n/a | X |  | 1. SESSKEY = 0 | First call
n/a | X |  | 2. SESSKEY != 0 | Not first call
n/a | X |  | 3. Pay any PAYEE | Capable of paying anyone
n/a | X |  | 4. BOL only account | Placed from a Bank Online only account
n/a | X |  | 5. Payment while disabling POL | Turning off Pay Online while making a payment
n/a | X |  | 6. BOL only account | Placed from a BOL only account but a second account is POL enabled
n/a | X |  | 7. DTDUE = earliest date possible | Payment made as soon as possible
n/a | X |  | 8. DTDUE = yesterday | Invalid payment date (date too soon)
n/a | X |  | 9. DTDUE = 1 year and 3 days in the future | Invalid payment date (date too future)
n/a | X |  | 10. DTDUE = a weekend | Invalid payment date (date is on a weekend)
n/a | X |  | 11. Valid PAYEEID | Payment made to the PAYEEID supplied by the server
n/a | X |  | 12. Invalid PAYEEID | Payment to a PAYEEID not on the server
n/a | X |  | 13. Multiple Payments (PAYEE) | Multiple payments to the same PAYEE for the same amounts on the same dates.
n/a | X |  | 14. Multiple Payments (PAYEEID) | Multiple payments to the same PAYEEID for the same amounts on the same dates.
n/a | X |  | 15. Optional MEMO | Payment with MEMO included
n/a | X |  | 16. ACTION = 2 | Standard PAYMTRQ, ACTION = 2
n/a | X |  | 17. ACTION = 10 | Standard PAYMTRQ, ACTION = 10
n/a | X |  | 18. DTDUE = 1 year ago | Invalid payment date (date too soon)
n/a | X |  | 19. Invalid SONRQ | Standard PAYMTRQ, placed with an invalid SONRQ
n/a | X |  | 20. Invalid BANKID | Non-standard PAYMTRQ, invalid BANKID
n/a | X |  | 21. TRNAMT is negative | Non-standard PAYMTRQ, the TRNAMT is a positive value
n/a |  | X | 22. DTDUE on a holiday* |
n/a |  | X | 23. Payment Limits* |
 |  |  | B. Cancel Savings Payments |
n/a | X |  | 1.Valid Cancellation |
n/a | X |  | a). Create a payment (PAYEE) | Payment DTDUE = Today + DaysToPay + 3 days
n/a | X |  | b). Cancel the payment | Standard PAYMTRQ to cancel
n/a | X |  | 2. Invalid Cancellation |
n/a | X |  | a). Create a payment (PAYEE) | Payment DTDUE = Today + DaysToPay (ASAP)
n/a | X |  | b). Cancel the payment | PAYMTRQ cancellation is invalid for payments made as soon as possible
n/a | X |  | 3. Valid Cancellation |
n/a | X |  | a). Create a payment (PAYEEID) | Payment made with PAYEEID, DTDUE = Today + DaysToPay + 3 days
n/a | X |  | b). Cancel the payment | Standard PAYMTRQ to cancel
n/a | X |  | c). Create the payment again | Verify that user is able to create the payment to that PAYEEID again
n/a | X |  | 4. Invalid SRVRTID |
n/a | X |  | a). Create a payment |
n/a | X |  | b). Cancel the payment | PAYMTRQ is made with an invalid SRVRTID
n/a | X |  | 5. Invalid payment information |
n/a | X |  | a). Create a payment |
n/a | X |  | b). Cancel the payment | Non-standard PAYMTRQ, the SRVRTID is valid, but the payment information does not match the original payment
 |  |  | VI. Payment Inquiries |
 |  |  | A. General |
n/a | X |  | 1. Valid Payment Inquiry |
n/a | X |  | a). Create a payment |
n/a | X |  | b). Valid SRVRTID | Inquire about the payment using the valid SRVRTID
n/a | X |  | 2. Invalid payment inquiry |
n/a | X |  | a). Create a payment |
n/a | X |  | b). Invalid SRVRTID | Inquire about the payment using an invalid SRVRTID
n/a | X |  | 3. Canceled payments |
n/a | X |  | a). Create a payment |
n/a | X |  | b). Cancel the payment |
n/a | X |  | c). Inquire on the canceled payment | Inquire about the canceled payment using the SRVRTID
n/a | X |  | 4. BOL only account |
n/a | X |  | a). Create a payment | The account is enabled for BOL and POL, and a valid payment is made.
n/a | X |  | b). Disable POL, and send a payment inquiry | Disable the accounts POL, and also send a standard payment inquiry
n/a | X |  | 5. Invalid SONRQ |
n/a | X |  | a). Create a payment |
n/a | X |  | b). Invalid SONRQ | Use an invalid SONRQ when requesting the payment inquiry
n/a | X |  | 6. Invalid ACTION |
n/a | X |  | a). Create a payment |
n/a | X |  | b). ACTION = 1 | Use ACTION = 1 when making the payment inquiry
n/a | X |  | c). ACTION = 20 | Use ACTION = 20 when making the payment inquiry
 |  | X | 7. Inquire on cleared payments* | Create a payment. Clear the payment on the server side and then inquire on the payment
 |  | X | 8. No < or > returned* | There should never be a < or > returned in the PAYIQRS memo element
 |  |  | VII. Payees |
 |  |  | A. Adding |
n/a | X |  | 1. SESSKEY = 0 | Adding a PAYEE on the user's first call
n/a | X |  | 2. SESSKEY != 0 | Adding a PAYEE when it is not the user's first call
n/a | X |  | 3. Optional PAYEEID | Non-standard PAYEERQ. Add a PAYEE using both the PAYEE aggregate and supplying the optional PAYEEID
n/a | X |  | 4. BOL only account | Non-standard PAYEERQ . Add a PAYEE from a Bank Online only account
n/a |  | X | 5. PAYEEID not returned* | Server does not include a PAYEEID in the PAYEERS
n/a |  | X | 6. Unsolicited payees, correct CLTID | Server should return the correct CLTID when responding with an unsolicited PAYEERS
n/a |  | X | 7. DAYSREQD & DAYSWITH | Server should return logical DAYSREQD and DAYSWITH within the PAYEERS
 |  |  | B. Changing |
n/a | X |  | 1. Valid PAYEEID |
n/a | X |  | a). Change the PAYEE | Use a valid PAYEEID to alter the PAYEE information on the server
n/a | X |  | b). Reset the PAYEE | return the PAYEE information to its original state
n/a | X |  | 2. Invalid PAYEEID | Non-standard PAYEERQ. Use an invalid PAYEEID to alter PAYEE information
n/a | X |  | 3. PAYEE but no PAYEEID | Non-standard PAYEERQ. Send a change request but no PAYEEID to change


MS Money Branding Toolkit

Microsoft Corporation

Created: November 1, 1996
Revised: November 12, 1996


Introduction

Financial Institutions choosing to offer Online Services with MS Money may take part in a unique branding program offered by Microsoft. This program offers partner financial institutions a flexible and dynamic way to maintain and enhance their financial services, while building a strong identity with their online customers. This program allows the institution to incorporate graphics as well as other information—such as a welcome message or important phone numbers specific to your institution—into the customer's customized view of Microsoft Money.

The Branding Toolkit has been provided with the OFC SDK so that developers and product managers may have access to this information during the server development process.


MS Money Branding Toolkit

Branding of Microsoft Money is accomplished through online access to a remote branding server managed and supported by Microsoft. This server is a centralized storage place for graphics (bitmaps) and other types of files that Money uses to customize the customer's interface. When customers install the online services of Money, the branding graphics are accessed and downloaded. It all happens automatically and is transparent to the user. The Financial Institution's branding graphics are displayed from the start—from the online services setup screens that appear when customers dial in to add online functionality, to the ongoing services they access from your institution.

The purpose of Branding Toolkit is to show you how graphics and text files are used in the branded Microsoft Money product and its setup, and to provide information that will help in preparing files for delivery to Microsoft.

Click here to access the Branding Toolkit:


Testing Online without a BDS connection

Ron Yerkes
Microsoft Corporation

Created: September 17, 1996
Revised:


Testing Online without a BDS connection

Follow the following instructions to configure MS Money for Online Testing (without requiring a connection to the Branding Directory Server).

-------------------------------------

To test online stuff without going to the branding server, you have to (a) tell the code that it's not going online, and (b) provide all of the information locally. The former is accomplished by setting the BDS's "Online" registry value:

[HKEY_LOCAL_MACHINE\Software\Microsoft\BDS\1.0]
Online="0"

The latter is accomplished by creating a local "default" tree that mirrors what bds.dll expects to find internationally. Assuming the Money install directory is "C:\Program Files\Microsoft Money", that means the following:

  • Create the directory hierarchy "C:\Program Files\Microsoft Money\system\bds\default".
  • Create a "default.ini" in the default directory. (A "summary.rtf" should probably be created as well.)
  • Create a directory and branding info for each "provider" listed in the default.ini.

Click here for a sample "default.ini" and "summary.rtf"

To use them directly, the subdirectories "test1" and "test2" should be created in the "default" directory, and populated with branding info. By the end of all of this, the local machine should have the following files:

  • C:\Program Files\Microsoft Money\system\bds\default\default.ini
  • C:\Program Files\Microsoft Money\system\bds\default\summary.rtf
  • C:\Program Files\Microsoft Money\system\bds\default\test1\bank.ini
  • C:\Program Files\Microsoft Money\system\bds\default\test1\other branding files
  • C:\Program Files\Microsoft Money\system\bds\default\test2\bank.ini
  • C:\Program Files\Microsoft Money\system\bds\default\test2\other branding files


Topic Not Found

No matching topic was found. Some possible reasons and remedies are as follows:

  • The file (.chm) that contains the destination topic is not in the expected location.

    Remedy: Rerun the MSDN Library Setup.

  • The file (.chm) that contains the current topic or destination topic is out-of-date and the link is no longer valid.

    Remedy: Install the latest version of the MSDN Library.

  • The MSDN Library CD is not in the CD-ROM drive.

    Remedy: Insert the MSDN Library CD into the CD-ROM drive.