Reference Models of Business Processes for Financial Services

Initial Submission to the

Reference Models of Business Processes for Financial ServicesRFP

Submitted by

Financial Services Technology Consortium (FSTC)
IP Commerce, Inc.
Unisys Corp.
Visa Inc.

Submitted to

OMG Finance Domain Task Force

11/19/2007

Document ~finance/2007-11-02

Submission Contact Points

Svetlana Sicular / Philippe De Smedt
Visa Inc.
/

Kevin Weber

Andera Inc.

Peter Tapling
Authentify Inc.

Dan Schutzer / Michael Versace

FSTC

Jeremy Lowell / David Johnson

IP Commerce, Inc.

Michael Halpern

Unisys Corp.

Sotos Barkas

Wells Fargo

San Francisco, CA

Table of Contents

VISA-etal_Submission.docPage 1 of 18

Introduction...... 4

1.1 Introduction to Reference Models of Business Processes for Financial Services....4

1.2 Business Goals...... 4

1.2.1 Today’s Challenges...... 4

1.2.2 Opportunities, Benefits...... 4

1.2.3 Principles for Capturing Requirements...... 5

1.3 Problem Statement and Scope of the Effort...... 5

1.4 Abstracting the Concept of Privacy – Further Elaboration...... 6

1.5 Creation of a Trust Model...... 8

2 Use of Normative Terminology...... 8

3 Glossary for Reference Models of Business Processes for Financial Services...... 9

3.1 Introduction and Overview...... 9

3.2 Glossary of Terms...... 9

4 Modeling Approach...... 9

5 Normative Specification...... 18

5.1 Introduction...... 18

5.2 Informal Overview of Artifacts...... 18

5.3 Other TBD...... 18

6 Conclusion...... 18

Introduction

1.1Introduction to Reference Models of Business Processes for Financial Services

Modeling the financial processes involved in account opening and funds transfer in a formal way is a first step in a broad industry effort to make business processes across the financial services industry more efficient and secure. Reference models for these processes are intended to elucidate the security issues across inter-enterprise financial services networks, and to provide an architectural framework for further elaboration of financial processes that create, carry or consume sensitive data. The financial services industry and their suppliers will use these reference models to collaboratively identify opportunities to improve security policy and controls. In particular, it is expected that redundancies and inefficiencies in existing processes, often the cause of security issues, will be addressed. This document is a response to the RFP, issued by the Finance Domain Task Force (FDTF) of the OMG, and intends to address[1] the following: the definition of standard reference models for account opening and funds transfer processes, and the definition of an architectural framework based on the reference models, intended to identify opportunities for improved security and privacy mechanisms, protocols, and policies.

1.2Business Goals

1.2.1Today’s Challenges

News of stolen identity, theft or compromise of account numbers, and irregularities in commercial transactions inevitably make buyers and sellers more cautious about when, where, with whom and how they pay and charge for purchases and open accounts. Government bodies are analyzing situations and are enacting more and more regulation.

Financial Institutions (FI) and their customers find that they frequently carry unnecessary or redundant sensitive information about transacting parties, information that could be eliminated if there were industry agreement to do so.

Most stakeholders lack incentives to invest in fundamental information exchange improvements because of well established and entrenched standards, suppliers and regulation. It is rare for a single stakeholder to take on such a challenge before the entire system is ready.

1.2.2Opportunities, Benefits

Updated standards for information exchange during account opening and funds transfer can leverage our society’s progression to mainstream use of computing (compared to simulation of paper processing using computers) and reduce barriers to commerce stemming from security and privacy concerns.

Transacting parties will then benefit from higher confidence that what they desire to be protected is indeed protected. Buyers and sellers will channel more effort to their business at hand and less effort to fixing errors and worrying about security and the mechanics of conducting commerce.

Government agencies will benefit from reduced effort of regulating security and privacy, while maintaining access to information required by law.

FIs will benefit from the expected increase in commerce, from reduced waste in processing and storing redundant information and from reduced operational risk, and reduced uncertainty and litigation surrounding security and privacy.

1.2.3Principles for Capturing Requirements

As this submission effort progresses through requirements analysis and the creation of models, there are principles to consider that are the foundation for success for such an ambitious project.

1.2.3.1A Financial Institution’s (FI) customers are private to the FI

For competitive reasons, an FI should not see another FI's customers. This may also be an expectation of the customer. A mechanism for some level of trust is needed to conduct commerce, even when an FI does not know and cannot find the details of another FI's customers.

1.2.3.2Authorities' privilege to identify stakeholders

A government authority with proper jurisdiction must be able to resolve data elements in a transaction to find which individuals conduct and benefit from a transaction. This implies resolving indirections from an organization to actual people that are stakeholders in the transaction in which the FI participates.

1.2.3.3Devalue IDs passed in information exchanges

The value of identifying information exchanged must be reduced for anyone other than the parties involved in the transaction. Substituting an unchanging ID with another is not a solution. Example: Social Security Numbers (SSN) have become a common way to identify a transacting party and a common vehicle for fraud. If tomorrow there is a different identifier, perhaps administered by a financial industry agent, the vulnerability may be reduced only temporarily.

1.2.3.4Allow for Incremental Migration from Present to Target State

The reference model must support a granular, modular way for transitioning to the final target. In particular, it is anticipated that the model will identify the major steps in the business processes, and apply a suitable abstraction of the specific implementation of each of the steps using interfaces and wrappers.

1.2.3.5Evolution

Both perceived and real threats to secure commerce change over time. Solutions must be architected for evolution, keeping in mind impacts to investments.

1.3Problem Statement and Scope of the Effort

As defined in section 6.0 of the RFP, the scope of this effort encompasses the account opening and funds transfer processes, with a specific emphasis on standardizing and reengineering these processes to address issues and inefficiencies in security.

This problem space can be further subdivided into two areas: retail banking and commercial banking. Retail banking processes involve individual consumers or small business customers, while commercial banking processes pertain to mid to large size business customers. While the account opening and funds transfer processes for these different types of customers are similar, there are enough differences that they need to be considered separately.

To address these differences, we propose to divide this effort into multiple phases[2]. The proposed phases are:

Retail Account Opening
Retail Funds Transfer
Commercial Account Opening
Commercial Funds Transfer

This response addresses the reference models for retail account opening. Subsequent revisions will address funds transfer and the commercial banking space. Retail account opening was selected as the first area of focus because this area touches on most of the security and privacy issues financial institutions and service providers encounter when attempting to automate these processes.

Retail account opening includes the following activities and functions:

Eligibility qualification
Primary and joint ownership applications
Account selection
Disclosure and forms handling
Electronic signature processing
Identity verification and authentication of applicants
Watch (e.g. OFAC) List verification
Debit and Credit Risk assessment
Account History assessment
Cross-selling of additional accounts or services
Initial funding of new account
Setup of the new account on the financial institution core system
Additional requirements handling (e.g., receipt of signature card)

Many of these activities involve interactions with third parties, so a key requirement in modeling this process is to define standardized services to support each of these activities.

1.4Abstracting the Concept of Privacy – Further Elaboration

The submission team determined that any model of the account opening process would need to take into account the concept of privacy – specifically data privacy. In this context, a working description of privacy could be presented as follows:

“Privacy: The acknowledgement that certain individual data values or collections of data values are owned by a person or company and use of those values should remain in control of the owner of the values. Processes which need to act against these data values should: a) use the data values only at the instruction of the owner as necessary to complete a process or provide a service requested by the owner; b) employ a “least possible exposure” approach when using the values; and, c) protect the values from inadvertent disclosure to unauthorized parties.”

Business processes in financial services, both automated and manual, struggle with balancing the contemporary view of privacy as described above with legacy processes and data structures. As a result, the implementation of privacy in practice has become a practice of encrypting everything whenever possible and creating legal agreements which spread liability in the case of data exposure. In the end, current systems still share too much data with too many parties who do not need access to the private data to provide their services.

In creating a modern model for the account opening process, the team would like to put forth an abstracted model for dealing with the issue of privacy at the model level. It is our hope that such an abstraction will enable a design which accounts for privacy in the modern sense and thereby reduces the exposure of private information and the commensurate liability for data handling that absorbed by providers of financial services.

In order to model privacy, the team discussed ways to abstract the concept such that it could be applied to data elements or collections of data elements. The contemporary view of privacy, at least for this purpose, is that individuals should be able to control information about them in the digital world or if information is shared have an expectation that it would be protected. There is also a regulatory landscape within which organizations that hold such data are bound to protect it in certain ways. However, such regulations vary across the world, and thus the notion of privacy is one that has no agreed upon common definition. The reference model should be flexible enough to support the various levels or interpretations of privacy that exist. However, where there exist opportunities to drive a common definition of privacy, the submitters will endeavor to provide one.

To create a framework for discussing a privacy model, we suggest that the privacy treatment of data derives from the ultimate owner of the data. Ownership here is the idea that the information at question is “about” the owner or describes the owner in some confidential way.

Within the model’s concept of ownership, data can be considered as:

a)not private;

b)private as owned data;

c)private under a fiduciary responsibility; or,

d)private as aggregated with other data elements.

These various concepts of why data might be private are all affected by a regulatory environment.

Figure 1. Model to discuss why data should be private.

Privacy in relation to data is in the end about how the data is used. A party holding data can be subject to permissions on how the data may be used, or they can give permissions on data use, or both. The sharing of data with business partners must be done under this context.

Using the model above, each data element can be tagged as to why it should be treated as private. Such a tag can also indicate the permitted uses of the data. Perhaps an “expiration date” would be useful as well – a date after which there is no reason to hold the data or the data must be “destroyed”.

There is also the concept of keeping the existence or nature of a transaction private, separate from the data values that may express that transaction. More work needs to be done to determine if/how to model this concept of transaction privacy.

1.5Creation of a Trust Model

An important requirement of the RFP is the creation of a model capturing the characteristics of trust among participants in a financial transaction. The submission team understands that this includes mechanisms for evaluating and specifying the trustworthiness of a participant, possibly through the use of 3rd party services or the application of a trust profile based on previous interactions with the participants. It also includes the application of that knowledge to decisions such as whether to conduct business with that participant, at what monetary level, and to what extent sensitive information may be exchanged with that participant.

Follow-on submissions will further elaborate on the topic of trust model and trust modeling language.

2Use of Normative Terminology

The submission team, going forward, will rigorously apply the following keywords as specified in RFC2119, “Key Words for use in RFCs to Indicate Requirement Levels”, issued by the Internet Engineering Task Force, March 1997. The relevant text of that RFC is excerpted below.

“The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119] as quoted here.

MUST: This word, or the terms "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the specification.

MUST NOT: This phrase, or the phrase "SHALL NOT", means that the definition is an absolute prohibition of the specification.

SHOULD: This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED", means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

MAY: This word, or the adjective "OPTIONAL", means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides).

3Glossary for Reference Models of Business Processes for Financial Services[3]

3.1Introduction and Overview

3.2Glossary[4] of Terms

Economic Agent / An Economic Agent is an individual or organization capable of having control over economic resources, and transferring or receiving the control to or from other individuals or organizations. Examples of economic agents are customers, users, financial institutions, vendors, employees, and enterprises.
Economic Event / An Economic Event represents either an increment or a decrement in the value of economic resources that are under the control of the enterprise. Some economic events occur instantaneously, such as sales of goods; some occur over time, such as rentals, labor acquisition, opening an account, transferring funds, and the provisioning and use of services.
Economic Resource / An EconomicResource is a thing that is scarce, and has utility for economic agents, and is something users of business applications want to plan, monitor, and control. Examples of economic resources are products and services, money, accounts, raw materials, labor, tools, and services the enterprise uses.
Class (Modeling) / The set (possibly zero) of all members that satisfy a specific type, in which case each entity is a member of that class
Class (UML) / The descriptor for a set of objects that share the same attributes, operations, methods, relationships and behavior.

Table 1 Glossary of Terms

4Modeling Approach

This section documents a modeling approach based on perspectives and viewpoints, such as those specified in RM-ODP, the Open Distributed Processing Reference Model, known as ISO 10746. The application of these principles to the problem at hand has resulted in a set of diagrams, which the team expects to become the basis for further elaboration of the reference models.

Before showing the diagrams applicable to the reference models, here are two diagrams that capture, at a high level, the basic tenets of the RM-ODP approach. They show, for each of the five viewpoints in the first diagram, what aspect of the system is being modeled, and what the output is of the application of each viewpoint. This is then applied to the initial set of models developed for the current specification.

Applied to the reference models under development, the following initial diagrams have been constructed.