reference models of business processes for financial services · web viewintroduction to reference...
TRANSCRIPT
Initial Submission to theReference Models of Business Processes
for Financial Services RFP
Submitted byFinancial Services Technology Consortium
(FSTC)IP Commerce, Inc.
Unisys Corp.Visa Inc.
Submitted toOMG Finance Domain Task Force
11/19/2007Document ~finance/2007-11-02
Copyright © 2007 Financial Services Technology Consortium (FSTC), IP Commerce, Inc., Unisys Corp., Visa Inc.
document.doc Page 1 of 19
Submission Contact Points
Svetlana Sicular / Philippe De SmedtVisa [email protected] / [email protected]
Kevin WeberAndera [email protected]
Peter TaplingAuthentify [email protected]
Dan Schutzer / Michael [email protected] / [email protected]
Jeremy Lowell / David JohnsonIP Commerce, [email protected] / [email protected]
Michael HalpernUnisys [email protected]
Sotos BarkasWells FargoSan Francisco, [email protected]
document.doc Page 2 of 19
Table of Contents
Introduction.........................................................................................................................41.1 Introduction to Reference Models of Business Processes for Financial Services.....41.2 Business Goals...........................................................................................................4
1.2.1 Today’s Challenges.............................................................................................41.2.2 Opportunities, Benefits.......................................................................................41.2.3 Principles for Capturing Requirements...............................................................5
1.3 Problem Statement and Scope of the Effort...............................................................51.4 Abstracting the Concept of Privacy – Further Elaboration........................................61.5 Creation of a Trust Model..........................................................................................8
2 Use of Normative Terminology........................................................................................83 Glossary for Reference Models of Business Processes for Financial Services................9
3.1 Introduction and Overview........................................................................................93.2 Glossary of Terms......................................................................................................9
4 Modeling Approach..........................................................................................................95 Normative Specification.................................................................................................18
5.1 Introduction..............................................................................................................185.2 Informal Overview of Artifacts...............................................................................185.3 Other TBD...............................................................................................................18
6 Conclusion......................................................................................................................18
document.doc Page 3 of 19
Introduction1.1 Introduction 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 address1 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.2 Business Goals1.2.1 Today’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.2 Opportunities, BenefitsUpdated 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.
1 Note that in this initial submission, only the beginnings of these deliverables are addressed. As the submission matures, each of these will be fleshed out. In particular, in this submission, the focus is on retail account opening.
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.3 Principles for Capturing RequirementsAs 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.1 A Financial Institution’s (FI) customers are private to the FIFor 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.2 Authorities' privilege to identify stakeholdersA 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.3 Devalue IDs passed in information exchangesThe 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.4 Allow for Incremental Migration from Present to Target StateThe 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.5 EvolutionBoth perceived and real threats to secure commerce change over time. Solutions must be architected for evolution, keeping in mind impacts to investments.
1.3 Problem Statement and Scope of the EffortAs 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 phases2. The proposed phases are:
1. Retail Account Opening2. Retail Funds Transfer3. Commercial Account Opening4. 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:o Eligibility qualificationo Primary and joint ownership applicationso Account selectiono Disclosure and forms handlingo Electronic signature processingo Identity verification and authentication of applicantso Watch (e.g. OFAC) List verificationo Debit and Credit Risk assessmento Account History assessmento Cross-selling of additional accounts or serviceso Initial funding of new accounto Setup of the new account on the financial institution core systemo 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.4 Abstracting the Concept of Privacy – Further ElaborationThe 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.”
2 Note that the final submission needs to include both account opening and funds transfer models, to satisfy the requirements of the RFP. The exact scheduling and timing of phases need to be determined by the submission team.
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.
Owner
Aggregated
Fiduciary
None
Regulatory
Figure 1. Model to discuss why data should be private.
Regulatory
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.5 Creation 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.
2 Use of Normative TerminologyThe 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).
3 Glossary for Reference Models of Business Processes for Financial Services3
3.1 Introduction and Overview
3.2 Glossary4 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 Economic Resource 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
4 Modeling ApproachThis section documents a modeling approach based on perspectives and viewpoints, such as those specified in RM-ODP, the Open Distributed Processing Reference
3 This is a very preliminary list, inserted here with no other intention than to give structure to the document.4 Note that the I2PADS project, the collaboration between FSTC and OMG on this topic, maintains a living glossary on its collaboration site. Participants are encouraged to update that document as necessary.
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.
11/16/2007 1
EnterpriseEnterpriseBusiness Aspects
The purpose, scope and policies for theorganization that will own the system
What for? why? who? when?
ComputationalComputationalApplication Design Aspects
Functional decomposition of the systeminto objects suitable for distribution
How does each bit work?
EngineeringEngineeringSolution Types & Distribution
Infrastructure required to support distributionHow do the bits work together?
TechnologyTechnologyImplementation
System hardware & softwareand actual distribution
With what?
ODPSystem
Information System AspectsInformation handled by the system andconstraints on the use and interpretation
of that informationWhat is it about?
InformationInformation
Reference Model for Open Distributed Processing (RM-ODP) Architectural Viewpoints
11/16/2007 2
EnterpriseViewpoint
Strategic View:• Purpose• Objectives• Scope• Roles • Enterprise objects• Processes• Policy statements• Actions performed by objects• Communities• Contracts• Environment contracts for enterprise objects
ComputationalViewpoint
Functional View:• Identification of computational objects• Components and connectors• Applications• Services• Interaction specifications• Interface specifications• Policies and constraints• Environment contracts for computational objects
InformationViewpoint
View of Shared Semantics:• Identification of set of information objects
• Static attributes• Behavioral specification• Relationship among the behaviors• Environment contracts for information objects
EngineeringViewpoint
Engineering & Middleware Support View:• Physical distribution• Communications• Infrastructure• Distributed bindings • Interconnection mechanisms• Functions and distribution Transparencies
TechnologyViewpoint
Technology & Standards View:• Choices of technology• Choices of standards• Choices of products• Configuration of technology objects• Specification of all technology interfaces• Technologies and mapping to standards• Conformance information
System
Network Grid
Workstation
Servers
Workstations
Mainframe
Data
SD
Sm art-U PS
6 2 0
www.ap cc.com
D
Sm ar t-U PS
6 2 0
www. pcc. com
UML for ODP Architectural Viewpoints
Applied to the reference models under development, the following initial diagrams have been constructed.
11/16/2007 Draft Only 1
Business Perspective: Global Financial Institution (FI) Community ContextBusiness Concerns and Organizational Perspective
<<Global Financial Institution (FI) Community Context>><<Client Community>> << Financial Institution Community (FI) Community>>
<<Recipient Community>>
<< Regulator Community>>
<<Role>>:Client<<Role>>
:Client
<<Role>>:SystemsAdministrator<<Role>>
:SystemsAdministrator
<<Role>>:SecurityAdministrator<<Role>>
:SecurityAdministrator
<<Role>>:Regulator<<Role>>
:Regulator
<<Role>>:Recipient<<Role>>
:Recipient
<<Client System>><<Client System>>
<< FI System>><< FI System>>
<< Regulator System>><< Regulator System>>
Environment Contracts
<<Resource>>:CreditLimit<<Resource>>
:CreditLimit
<<Event>>:AccountSignUp<<Event>>
:AccountSignUp
<<Role>>:Recipient FI<<Role>>
:Recipient FI
<<Role>>:Client FI<<Role>>
:Client FI
<<Role>>:Intermediary FI<<Role>>
:Intermediary FI
<<Role>>:Credential Authority<<Role>>
:Credential Authority<<Recipient System>><<Recipient System>>
<< Other TBD Community>>
<<Role>>:Other TBD<<Role>>
:Other TBD<< Other TBD System>><< Other TBD System>>
11/16/2007 Draft Only 2
Business Perspective: Client Community
<<Client Community >>
<<Role>>:Client
qualifyForEligibility();applyForPrimaryAccount();applyForJointOwnershipAccount();
<<Role>>:Client
qualifyForEligibility();applyForPrimaryAccount();applyForJointOwnershipAccount();
<<Client System>><<Client System>>
<<Policy>>:Client
Obligated to provide specific form of identificationProhibited from applying for someone elsePermitted to ….etc…
<<Policy>>:Client
Obligated to provide specific form of identificationProhibited from applying for someone elsePermitted to ….etc…
<<trace>>
11/16/2007 Draft Only 3
Environment Contract: Defining the Interoperability Interfaces
Subject
Parties
Pre-conditionsPost-conditionsInvariants
Policies ofEnvironment• Obligation• Permission• Prohibition• Violation• Authorization
Performance(QoS)• Availability constraints• Capacity constraints• Volume (Throughput)
constraints• Reliability constraints• Response-time constraints• Maintainability constraints• Safety constraints• Security constraints
Roles
Usage Constraints• Location
– time constraints• Arrival Patterns• Synchronization Patterns• Reaction Time• Deadlines
• Location– space constraintsgeographic coverage
Duration of validity, andWhen the contract becomes valid
Management Constraints• Fault tolerance• Network Management• Security Management
Distribution Transparencies• Access• Location• Failure• Migration• Relocation• Persistence• Replication• Transaction
Not all of these elements will be required but it will provide a framework for discussion about the nature of the contract between the Client and the Account holding Financial Institution (FI).
11/16/2007 Draft Only 4
<< Financial Institution Community>>
Information Viewpoint: Static
:Account:Account
:Client:Client
Data Concerns, Semantics, Relationships and Transformations
:Report:Report
:Message:Message
:Transactions:Transactions
:Settings:Settings
:Administrator:Administrator:Profile:Profile
11/16/2007 Draft Only 5
Information Viewpoint: Activity Diagram - Example OnlyActivity and Object/Information Flow Concerns
doActivity 1doActivity 1
doActivity 2doActivity 2
<xx
doActivity 4doActivity 4
start
doActivity 3doActivity 3
end
:Account Number:Account Number
[Yes] [No]
<<Technology >>
Product ABCD<<Technology >>
Product ABCD<<Use>>
Dependency relationships are used to model a wide range of dependent relationships between model elements in activity and structural diagrams, and between the viewpoint models themselves.
Object
11/16/2007 Draft Only 6
<< Regulatory Community>>
<< Financial Institution Community>><<Client Community>>
Computational Viewpoint
:Client:Client :FinancialService:FinancialService
<<Component>>:RegulatoryBody<<Component>>
:RegulatoryBody
<<Datastore>>:db0<<Datastore>>
:db0
<<Datastore>>:db1<<Datastore>>
:db1
<<Datastore>>:db2<<Datastore>>
:db2
InteroperabilityInterfaces
Connector 1
Connector 2
Computational and Functional and Services Concerns
<<Technology >>
Product ABCD<<Technology >>
Product ABCD
<<Use>>
11/16/2007 Draft Only 7
<<Regulatory Community>>
<<Financial Institution Community>><<Client Community Context>>
Engineering Viewpoint
<<Node>>
:Client
<<Node>>
:FinancialService
<<Node>>
:RegulatoryBody
Physical Concerns, Decomposition and Connectivity
Channel A
Channel B
<<Datastore>>
<<Datastore>>
<<Datastore>>
<<Datastore>>
<<Datastore>>
<<Datastore>>
<<Datastore>>
<<Datastore>><<Datastore>>
PresentationPresentation
BusinessBusiness
ServicesServices
IntegrationIntegration
:FinancialService:FinancialServiceSecu
rity
Secu
rity
11/16/2007 Draft Only 8
<<Regulatory Community>>
Technology Viewpoint<< Financial Institution Community >>
<<Client Community>>
<<Node>>
:Client
<<Node>>
:Financial Service
<<Node>>
:RegulatoryBody
Internet
Internet
<<Datastore>>
<<Datastore>>
<<Datastore>>Seibel
<<Datastore>>
<<Datastore>>
<<Datastore>>IBM DB2
<<Datastore>>Microsoft
<<Datastore>><<Datastore>>Oracle
HTTPS
Technology Products, Technology Standards, Conformance Test
My Page
IE6.x/Firefox
ABCD Product
ABCD
Presentation(JavaBean/JSP/servlet)Presentation
(JavaBean/JSP/servlet)
Business(JavaBean, POJO, EJ B)Business
(JavaBean, POJO, EJ B)
Services(Application & System)Services
(Application & System)
Integration(JMS Message Bus/Message Beans)
(JDBC and J2EE Connectors)(Java API’s)
Integration(JMS Message Bus/Message Beans)
(JDBC and J2EE Connectors)(Java API’s)
Secu
rity
Secu
rity
5 Normative Specification5
5.1 Introduction
5.2 Informal Overview of Artifacts
5.3 Other TBD
6 ConclusionThe present submission documents the work of the submission team so far, and is a compilation of the business goals and problem statement developed, and the initial framework for reasoning about these business processes.
The submission will be further elaborated on in bi-weekly conference calls and face-to-face meeting(s). The next submission will be prepared prior to the March, 2008 OMG meeting.
5 In the final submission, there will be a normative section and possibly a non-normative one. This header is included here to provide an area for insertion of the normative portion.