Université du Québec à Montréal. Financial Services Logical Data Model for Social Economy based on Universal Data Models. Project

Transcription

1 Université du Québec à Montréal Financial Services Logical Data Model for Social Economy based on Universal Data Models Project In partial fulfillment of the requirements for the degree of Master in Software Engineering by Grazia Coppola Winter 2010

2 Financial Services logical data model for Social Economy based on UDM / 132

3 Financial Services logical data model for Social Economy based on UDM / 132 Table of Contents Table of Figures...8 Table of Tables...9 Acronyms and Abbreviations Introduction Intended Audience Problem Definition Objective What is a Data Model? Logical Data Models What are Universal Data Models? Approach High Level Use Cases Actors Overall Process New Project Process Functional Areas and Data Subject Areas Contact Management Directory Management Directory Management Feature List and Business Rules Directory Management Conceptual Data Model People and Organization (PARTY) Logical Data Model Mapping Key Data Concepts to UDM Entities PEOPLE and ORGANIZATION Entities and Attributes PARTY Data Examples Contact Mechanism Logical Data Model CONTACT MECHANISM Entities and Attributes CONTACT MECHANISM Data Examples Communication Event Logical Data Model Communication Event Feature List Communication Event Logical Data Model COMMUNICATION EVENT Entities and Attributes COMMUNICATION EVENT Data Examples Contact Management Observations and Findings People and Organization Contact Mechanism Communication Event Financial Product Management Financial Product Management Financial Product Management Feature List Financial Product Management Logical Data Model Financial Product Management Entities and Attributes Financial Product Management Data Examples Financial Product Management Observations and Findings Financial Product Regulations and Rules Management Financial Product Regulations and Rules Management Logical Data Model Financial Product Regulations and Rules Management Entities and Attributes...46

4 Financial Services logical data model for Social Economy based on UDM / FINANCIAL PRODUCT RULE Data Example Financial Product Regulations and Rules Management Observations and Findings Financial Agreement Management Contract Management Contract Management Feature List and Business Rules Financial Agreement Management Logical Data Model Financial Agreement Management Entities and Attributes Financial Agreement Management Observations and Findings Account Management Account Management Account Management Feature List and Business Rules Account Management Logical Data Model Account Management Entities and Attributes Account Transaction Management Logical Data Model Account Transaction Management Entities and Attributes ACCOUNT TRANSACTION Data Examples Account Management Observations and Findings Invoicing and Payment Management Billing and Payment Processing Billing and Payment Processing Feature List and Business Rules Invoicing and Payment Management Logical Data Model Invoicing and Payment Management Entities and Attributes Invoicing and Payment Management Observations and Findings Work Effort Management Project Management Project Management Feature List and Business Rules Work Effort (Account Notification) Management Logical Data Model Work Effort (Account Notification) Management Entities and Attributes Risk Analysis Risk Analysis Risk Analysis Feature List Risk Analysis Logical Data Model Risk Analysis Entities and Attributes Risk Analysis Data Example Risk Analysis Observations and Findings Budget Planning Financial Plan Logical Data Model Financial Plan Entities and Attributes Work Effort Observations and Findings Findings Universal Data Model support for Requirements General Criteria for Evaluating a Data Model Summary of Findings by Functional Area Other Findings Recommendations Conclusion Future Work Other Requirements Other Requirements Glossary of Terms...75 Bibliography...77 Books...77

5 Financial Services logical data model for Social Economy based on UDM / 132 Articles / Papers / Documents...77 Sites Web Appendix A - Contact Management Directory Management Feature List and Business Rules People and Organization Entities and Attributes Party Person Organization Party Type Financial Institution Government Agency Local Development Fund Enterprise Job Statistics Party Role Party Role Type Contact Principle Contact Employee Internal Organization Customer Supplier Partner Party Relationship Party Relationship Type Contact Mechanism Entities and Attributes Contact Mechanism Telecom Number Electronic Address Postal Address Contact Mechanism Type Party Contact Mechanism Party Contact Mechanism Purpose Contact Mechanism Purpose Type Geographic Boundary Contact Mechanism Boundary Geographic Boundary Type Geographic Boundary Association Geographic Boundary Association Type Communication Event Feature List Communication Event Entities and Attributes Communication Event Face to Face Communication Phone Communication Communication Event Purpose Communication Event Purpose Type Communication Event Status Communication Event Status Type Case Case Role Case Status Type Appendix B Product Management...97

6 Financial Services logical data model for Social Economy based on UDM / Product Management Feature List Product Management Entities and Attributes Financial Product Product Category Product Category Classification Product Feature Product Feature Applicability Functional Setting Functional Setting Applicability Financial Product Regulations and Rules Management Entities and Attributes Financial Regulation Regulation Requirement Financial Product Rule Appendix C Financial Agreement Management Contract Management Feature List and Business Rules Financial Agreement Management Entities and Attributes Financial Agreement Agreement Type Agreement Item Agreement Term Agreement Term Type Agreement Role Agreement Role Type Asset Appendix D - Account Management Account Management Feature List and Business Rules Account Management Entities and Attributes Account Loan Account Account Status Account Status Type Account Role Account Role Type Account Product Account Transaction Management Entities and Attributes Appendix E - Work Effort Management Project Management Feature List and Business Rules Work Effort (Account Notification) Management Entities and Attributes Work Effort Work Effort Status Work Effort Status Type Notification Task Internal Task Invoicing Task Statement Task Alert Task Marketing Task Other Notification Task Account Notification Internal Notification Risk Analysis Feature List Risk Analysis Entities and Attributes

7 Financial Services logical data model for Social Economy based on UDM / Risk Analysis Risk Analysis Subject Risk Analysis Subject Type Analysis Outcome Risk Analysis Result Parameter Type Analysis Parameter Budget Plan Feature List Financial Plan Entities and Attributes Financial Plan Financial Plan Type Financial Plan Status Type Expense Expense Item Financing Financing Item Appendix F Invoicing and Payment Management Billing and Payment Processing Feature List and Business Rules Invoicing and Payment Management Entities and Attributes Invoice Invoice Type Invoice Item Invoice Status Invoice Status Type Payment Application Account Payment Payment Method Type Appendix G - Mapping of SSFA entities to Universal Data Model Entities Appendix H French / English Terms

8 Financial Services logical data model for Social Economy based on UDM / 132 Table of Figures Figure 1: Example of the UML notation used in this paper...15 Figure 2: High Level Process Diagram...19 Figure 3: High Level Use Case Diagram...20 Figure 4: process flow from receipt of initial request to preparation of a contract Figure 5: process flow from signing of a contract to completion of the service Figure 6: Mapping of Key Concepts to Universal Data Model Subject Areas...25 Figure 7: SSFA Functional Areas and Subject Area...26 Figure 8: Directory Management Conceptual Data Model Diagram...28 Figure 9: People and Organization PARTY logical data model diagram...29 Figure 10: ORGANIZATION CONTACT RELATIONSHIP logical data model diagram...30 Figure 11: ORG PRINCIPLE CONTACT RELATIONSHIP logical data model diagram...31 Figure 12: CONTACT MECHANISM logical data model diagram...33 Figure 13: GEOGRAPHIC BOUNDARY Subtypes...34 Figure 14: COMMUNICATION EVENT logical data model diagram...37 Figure 15: Financial Product Management logical data model diagram...43 Figure 16: Financial Product Regulations and Rules Management logical data model diagram...46 Figure 17: Financial Agreement Management logical data model diagram...49 Figure 18: Account Management logical data model diagram...52 Figure 19: Account Transaction Management logical data model diagram...53 Figure 20: Invoicing and Payment Management logical data model diagram...56 Figure 21: Work Effort (Account Notification) Management logical data model diagram...60 Figure 22: Risk Analysis logical data model diagram...62 Figure 23: Financial Plan logical data model diagram...64

9 Financial Services logical data model for Social Economy based on UDM / 132 Table of Tables Table 1-1: Comparison of features for the three types of data models...14 Table 4-1: Functional Area and UDM Subject Area Scope...24 Table 5-1: Mapping Key Data Concepts to UDM Entities...31 Table 5-2: PARTY data example...32 Table 5-3: PARTY RELATIONSHIP data example...32 Table 5-4: CONTACT MECHANISM PURPOSE data examples...35 Table 5-5: CONTACT MECHANISM and GEOGRAPHIC BOUNDARY data examples...35 Table 5-6: CONTACT MECHANISM BOUNDARY data examples...36 Table 5-7: GEOGRAPHIC BOUNDARY ASSOCIATION data examples...36 Table 5-8: GEOGRAPHIC BOUNDARY data examples...36 Table 5-9: GEOGRAPHIC BOUNDARY ASSOCIATION TYPE data examples...36 Table 5-10: COMMUNICATION EVENT data example...38 Table 5-11: COMMUNICATION EVENT PURPOSE data example...39 Table 5-12: COMMUNICATION EVENT and CASE data example...39 Table 6-1: PRODUCT FEATURE and FUNCTIONAL SETTING relationship examples...44 Table 6-2 FINANCIAL PRODUCT data example...44 Table 6-3: FINANCIAL PRODUCT RULES data example...47 Table 8-1: ACCOUNT TRANSACTION data example...54 Table 8-2: ACCOUNT TRANSACTION TASK data example...54 Table 10-1: Mapping Project Management information to UDM Subject Areas...58 Table 10-2: RISK ANALYSIS data example...63 Table 11-1: General Criteria for Evaluating a Data Model...67 Table 11-2: Summary of Findings by Functional Area...69

10 Financial Services logical data model for Social Economy based on UDM / 132 Acronyms and Abbreviations Terms AI2L API (the) Chair DTES gif IT jpeg PDF SME SSFA UDM UML Definitions Association Internationale du Logiciel Libre Application Programming Interfaces The Chair for Open Source Software for Social and Solidarity Finance of the Department of Information Technology at University of Quebec at Montreal Desjardins Transaction Express Services Graphics Interchange Format (an image format) Information Technology Joint Photographic Experts Group, an image format Portable Document Format Small and Medium size Enterprise Social and Solidarity Finance Application. Refers to the open source software for social and solidarity financial services. This software will be delivered as product line by the Chair which includes a set of financial services application. A name for the product line has yet to be given by the Chair, SSFA is an acronym given by the author in this paper to facilitate writing and reading of the paper. Universal Data Models Unified Modeling Language

11 Financial Services logical data model for Social Economy based on UDM / Introduction The Chair for Open Source Software for Social and Solidarity Finance of the Department of Information Technology 1 at University of Quebec at Montreal has the goal of establishing the foundation for a family of open source software products for social and solidarity financial services. The Chair will act as the incubator for the development of a financial services product line of applications that would eventually be transferred over to the chair s funding partner, the Association Internationale du Logiciel Libre (AI2L) for the social economy. AI2L currently consists of six organizations, three are based in France and three are based in Quebec. The AI2L has the responsibility of providing the specifications for the software applications and will ultimately be responsible for the distribution of the software to its members in the social economy community. The Chair s understanding is that the majority of the organizations that are part of the social economy interested in the financial services applications to be developed are small and medium size enterprises (SMEs). The enterprises all offer some form of financial services and products to their clients. It is a known fact that the financial services offered by these organizations will vary from organization to organization. Following are the six members of AI2L and a very brief description of the type of services and products they offer: 1. Caisse d'économie solidaire (Quebec): offers financial services to both enterprises and individuals. This cooperative financial institution offers a variety of services and products including loans, savings plans, insurance, and also payment services like credit card and debit card. 2. Crédit Coopératif (France): a cooperative bank offering to its mostly business clients a full range of financial banking services. 3. Groupe Chèque Déjeuner (France): offers a wide variety of services and products to organizations and individuals, products like credit cards and certificates that can be used to purchase goods and services essential to daily life (e.g. food, clothing and transportation) and also for entertainment services. 4. (Quebec): is a non-profit organization that provides loans to local development funds and SMEs. 5. Fondaction (Quebec): a worker s fund that provides a wide variety of savings plans to its members. It is also heavily involved in investing in businesses to help maintain and create new jobs in the Quebec market. 6. La Macif (France): a mutual insurance company offering to its members a variety of insurance plans, saving plans and credit. Based on the diversity of financial services and products offered by these six AI2L founding members it is obvious that to develop a software application that meets all the needs of each organization involved in the social economy is next to impossible. The Chair, with its limited resources, has as an objective to develop a solid application architecture and a generic financial services application that can be extended to meet as many as possible the varying needs of social economy organizations. The term generic is used to mean that the application must be designed with an extensible architecture allowing for flexibility for the addition of new products and services with relative ease. A key element for the success of such an application is the structure of the data to support the business functions. This 1 In French: La Chaire de logiciel libre- Finance sociale et solidaire, will be referred to as the Chair in the rest of this document.

12 Financial Services logical data model for Social Economy based on UDM / 132 paper addresses what the structure of the data would look like to be able to meet the varying needs of the organizations planning to deploy the open source software for social and solidarity finance. 1.1 Intended Audience This paper has been requested by the chairman of the Chair, Professor Louis Martin and will also be presented to members of the Chair s funding partner, AI2L. Its main target audience are the architects and developers of the software. The business requirements and the data structures presented in this paper are indented to serve as an initial base for building a prototype of the open source software for Social and Solidarity Finance Application (SSFA) to test key architectural decisions and deliver an application that can be used to elicit further requirements. It is assumed that the reader has some familiarity with entity relationship modelling and its notation. 1.2 Problem Definition The Chair has as a goal to develop a financial services software application that is flexible to meet as many as possible the requirements of various social economy organizations that offers financial services and management of these services to its customers. Although the Chair is developing open source software and the code would be made widely available, the objective is to provide software that is customizable through configuration and not requiring code changes to meet user requirements. Also to note, the Chair understands that most of the social economy Financial Services organizations do not have the technical resources to customize software code. The Chair has recommended the following high level architectural decisions, to help deliver an extensible architecture to meet the requirements for a software solution that is highly flexible and easily customizable without the need to redesign or access code to add new financial services functions: 1. The use of a business rules engine to manage and evaluate business rules, allowing for dynamic modifications of business rules. 2. The use of a business process engine to coordinate the execution of business process activities. 3. Use PostgreSQL, an open source Relational Data Base Management System (RDBMS), to store and maintain data records. 4. And the adoption of polyglot programming to allow for the right programming language for the task at hand; though the main programming languages will be Java, an object oriented language. The decision to use a business rules engine and business process engine is based on the need for application flexibility that will allow for business functions and business rules to be maintained outside of the core application program code. This is a move away from the object-oriented paradigm where software developers manipulate data and functions within an object. This decoupling of the data from the functions will require that the software developers build separate function and data models. Also that implies that the developers need to design the application to allow for flexibility to introduce new business functions into the application and to design extensible data architecture to support the varying requirements of Financial Services organizations. A key point to note is that business rules engines and business process engines exist to manipulate business data, making the structure of the data a crucial element to the success of the software solution.

13 Financial Services logical data model for Social Economy based on UDM / 132 The integrity and correctness of data is of great importance to financial services organizations. The data typically outlives the life of an application; it is typically migrated or converted in one form or another to the replacement application or made accessible for different uses as the business evolves. The challenge addressed in this paper is to answer how to best develop a data structure needed to support a generic and flexible financial service software application, given the limited availability of business domain expertise on the Chair and the limited resources to develop a good quality data model. The obvious answer was to search for re-usable data structures. Reuse is a very common and encouraged practice in the Information Technology (IT) industry. Besides reusable software components/modules and design patterns there exists a number of re-usable data structures. Len Silverston has written three books and numerous articles on the topic of re-useable data structures which he refers to as Universal Data Models. 2 These models are intended to jumpstart 3 the development of high quality data models that will result in data structures that can easily evolve or be extended. 1.3 Objective The objective of this paper is to investigate if the Universal Data Models (UDM) proposed by Len Silverston can be used as a starting point for developing the need data structures required to support the varying needs of social economy financial services organizations. Since data does not stand on its own in that it only makes sense in terms of the business activities it supports,, a member of AI2L, offered to provide a set business functions bases on their current Lotus Notes application which uses to manage their business. Validation of the usefulness and applicability of UDM is supported by analyzing s current Lotus Notes application to derive a list of requirements and business rules and mapping those requirements against the data models described in the Universal Data Models. 1.4 What is a Data Model? A data model defines the structure of the data to support the business activities. A data model is developed through a known data modeling process which involves: 1. The analysis of business functions and their required information 2. Data design activities 3. Producing full documentation of the data model. The data model documentation contains at a minimum: 1. Entities 4 and their descriptions 2. An Entity Relationship Diagram, a graphical representation of the entities and their relationships, using widely understood common syntax so that they may be understood by business analysts 3. Entity attributes: the pieces of data that describe an entity 4. Entity primary key: consists of one or more data attributes that uniquely identify a specific instance of an entity 5. Entity foreign keys: are data attributes that define relationships between entities, used to navigate between the different instances of an entity. Also known as referential attributes, since they are a primary key of another entity. 2 TM 3 To quickly and successfully set into motion. 4 A person, object, place or event for which data is collected and stored in a database.

14 Financial Services logical data model for Social Economy based on UDM / 132 The data modeling process involves the development of three different levels of data models starting with the Conceptual Data Model whose purpose is to facilitate communication between the data modeller and the business. This data model is defined in business terminology, describes the data things of interest (aka data entities) at a high level and how they relate to one another. The Conceptual Data Model is technology independent. The second model is the logical data model (LDM) which focuses on understanding and documenting the details of the data. It uses as input the Conceptual Data Model and further details the entities and their relationships to place them into structures that facilitate their implementation in a RDBMS using data modeling techniques designed for building good quality data bases. The LDM details include attributes of the entities, primary keys and foreign keys. The LDM also does not contain database platform specifics. The third and final data model is the Physical Data Model which incorporates any changes to the Logical Data Model required to implement the data in the physical RDBMS of choice and to achieve the required performance. The following table summarizes the three different levels of data models and which features are detailed in each. Table 1-1: Comparison of features for the three types of data models Feature Conceptual Logical Physical Entity Names Entity Relationships Attributes Primary Keys Foreign Keys Alternate Keys Table Names Column Names Column Data Types Indexes Adapted from: Logical Data Models The data models presented in this a paper are logical data models, their purpose is to understand the data structure required to address the basic business needs as understood at the time of writing based on an analysis performed on the needs of and limited knowledge of the Financial Services domain. The data models are by no means complete, they are an initial logical data model, deemed good enough to evaluate if the UDM defined by Len Silverston are a good starting point logical data models for SSFA. The logical data model diagrams presented in this paper use the Unified Modeling Language (UML) notation. Although UML is not the most ideal notation for describing data entity relationship models it was chosen since it is the notation language most developers are familiar with. In the data model diagrams the data entities are shown as UML classes, entity relationships are shown as associations including multiplicity, and association ends are used to describe the relationship. Since most of the LDM diagrams contain several entities, to keep the diagrams legible the primary key, foreign keys and attributes are not shown in the diagrams, they are provided with the entity description in the Appendix sections of this paper.

15 Financial Services logical data model for Social Economy based on UDM / 132 Figure 1: Example of the UML notation used in this paper The above diagram reads as follows: Each ORDER may be composed of zero or many ORDER ITEMs. Each ORDER ITEM must be part of one and only one ORDER. SALES ORDER and PURCHASE ORDER are subtypes of ORDER or ORDER is a supertype of SALES ORDER and PURCHASE ORDER. Note: Entity names are written in capital letters. Subtypes represent the set of possible classifications of an entity that has characteristics such as attributes or relationships in common with the more general (supertype) entity, hence the attributes and relationships of the supertype are inherited by the subtype. In the above diagram SALES ORDER is a subtype of ORDER. ORDER is the supertype for SALES ORDER and PURCHASE ORDER. The TYPE entities (e.g. ORDER TYPE in Figure 1), represent a classification, these entities store the complete set of values allowed for the entity (ORDER), some which may not appear in the diagram. Note: An important element of a logical data model is the documentation of the entities and their attributes. The entity descriptions provided in the Appendix sections of this paper are based on the entity descriptions provided in The Data Model Resource Book Volumes 1 5, Volume 2 6 and Volume The Data Model Resource Book, Volume 1, A Library of Universal Data Models for all Enterprises, by Len Silverston, 2001, John Wiley & Sons, Inc. [BB-1] 6 The Data Model Resource Book, Volume 2, A Library of Universal Data Models by Industry Types, by Len Silverston, 2001, John Wiley & Sons, Inc. [BB-2] 7 The Data Model Resource Book, Volume 3, Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, 2009, Wiley Publishing, Inc. [BB-3]

16 Financial Services logical data model for Social Economy based on UDM / What are Universal Data Models? Len Silverston is an author of several articles and three books on the topic of Universal Data Models. Volume 1 [BB-1] of The Data Model Resource Book presents data models for data common to all types of enterprises, such as People, Organizations, Human Resources, Products, Invoices, Accounting and Budgeting. Volume 2 [BB-2] shows how to extends the standard models presented in Volume 1 to address industry specific data modeling requirements for a variety of industries such as Manufacturing, Financial Services and Insurance. Volume 3 [BB-3] provides a library of templates and alternatives for common universal patterns or themes in data modeling that appear over and over again in most data modeling such as ways to model roles, statuses, classification, hierarchies, business rules and contact information. 8 The models presented are universal since they describe generalized and abstract set of entities, relationships and attributes modeled to support common data needs and to facilitate the extendibility and evolution of the data models to address specific business needs. Mr. Silverston emphasises that there is no such thing as a right data model his models provide alternatives to modeling various structures and point out the pros and cons of each 9. According Mr. Silverston the UDM are most beneficial to data modellers. UDM represent a repository of reusable logical data models that can easily be extended and customized. They are based on the experience of professionals and have gone through several iterations. Using UDM would save time and effort by leveraging on the reuse of good quality data models. In addition the UDM provide a holistic perspective, hence allowing for data modellers to proactively inquire, validate and explore about possible information requirements, this aspect is especially beneficial when the data modeller initiates data modeling activities with limited domain knowledge. In short the UDM are essentially a toolkit of best practices data structures for data modeling that have been proven and successfully implemented in industry. 8 Interview with Len Silverston of Universal Data Models by Robert S. Seiner and Len Silverston, April 2009, The Data Administration Newsletter, LLC [BA-1] 9 Universal Data Models: Simsion interviews Silverston, October 2003, Wilshire Conferences [BA-2]

17 Financial Services logical data model for Social Economy based on UDM / Approach The objective of this paper is to validate the claimed benefits of using the UDM to jump start the creation of good quality logical data models. An analysis of s Lotus Notes application was done to allow for validation of the Universal Data Models. It is understood that the analysis of one organization s functions and data is not enough to validate a generic data model; the plan is to conduct a similar analysis with at least one more organization that provides financial services in the social economy before a prototype of SSFA is developed. The following outlines the series of activities carried out in an iterative fashion, each time further refining the business requirements and the data models to support those requirements: 1. Analyze overall requirements: i. Extract and analyze requirements, by analyzing their current Lotus Notes application user guides which provide the functional capabilities and data elements of the application ii. Hold work sessions and meeting with personnel for further clarification of the requirements iii. Develop a High Level Use Case Model to identify the system boundaries iv. Develop an Overall Process Diagram for v. Review and validate the above high level documents with the business analyst vi. Produce an overall Conceptual Data Model to identify the key data concepts (aka Subject Areas) and the Functional Areas that the requirements address. 2. Gain overall understanding of the UDM: i. Review the 3 volumes of The Data Model Resource Book by Len Silverton ii. Identify the Universal Data Models that address the Functional Areas and Subject Areas needed to meet the requirements. 3. Further analysis of requirements: i. Conduct a more detail analysis of the business requirements and business rules ii. Document to validate the business requirements and rules with the business analyst. 4. Develop a logical data model for each Functional Area: i. Analyze the appropriate Universal Data Models, specifically the entities, relationships and their attributes ii. Map the entities to the UDM entities iii. Produce the logical data models for the Subject Area using the UDM as the base and extend them with the requirements iv. For the more complex entities provide examples of the entities with sample data to help better understand the data model v. Identifying any gaps between the needed data structures and the UDM (if any) vi. Document observations or findings regarding the use of the UDM as starter logical data model for the Functional Area. The above process was used to produce for each Functional Area the following documentation: 1. feature list of general business requirements and business rules. 2. SSFA logical data model diagram based on the UDM and extended to include data requirements.

18 Financial Services logical data model for Social Economy based on UDM / SSFA logical data model documentation which includes description of entities, primary and foreign keys and attributes. 4. Observations and findings regarding the use of UDM as a starter model. To document the business requirements it was deemed sufficient to produce a list of features rather than document the requirements in Use Cases, since the main objective of this paper is to document the logical data model and not the detail functional requirements. To document the requirements in Use Case format would necessitate an analysis of the User Interface required for the SSFA solution which is believed will be very different than the current Lotus Notes User Interface.

19 Financial Services logical data model for Social Economy based on UDM / The following section provides a description of s process, functions and required data. is a non-profit organization that provides loans and loans associated financial services to Local Development Funds and SMEs. The Local Development Funds in turn loan money to various organization in their jurisdiction. Some of Local Development Funds are given access to the Lotus Notes application to manage the loans they provide to their clients. In this case the Local Development Fund is given access to a complete separate instance on the Lotus Notes application (including data base), provides the application and the environment to execute the application. The overall process for to provide services is as show in the following diagram. Figure 2: High Level Process Diagram The above diagram shows a request for financial services is made by a potential customer, will analyse the request, if the request is approved by the Board of Directors a contract is prepared, a project is created to manage the service and the financial service is delivered to the customer. At pre-established periods will collect payments for the service and monitors the progress of the customer s ability to pay for the service. Once the customer has completely paid for the service the project is closed. 3.1 High Level Use Cases Use cases provide functional descriptions of a system s behaviour. The following diagram shows the high level use cases depicting the main functions of the Lotus Notes application that wished to replace with a new financial services application.

20 Financial Services logical data model for Social Economy based on UDM / 132 Figure 3: High Level Use Case Diagram Following is a brief description of each high level use case: Manage Company Directory: Allows for the managing of contact type information. requires that all persons or organizations its employees have business dealings with be included in the contact database. Manage Project: Once and a customer have reached an agreement regarding a financial service that will provide, the complete management of that service is handled under an umbrella of what refers to as a Project. Manage Loans and Other Services: s main service is to provide loans with varying parameters to Local Development Funds and other SMEs. also provides other financial services like guarantees. This high level uses case addresses the management of the disbursement, re-payments loans and other financial services. Manage Contract: All services provided to customers require some form of agreement or contract with signatures, this use case addresses the management of the contract terms and conditions for services provided to a customer. Track Customer Communication: requires that all communications exchanges between its employees and customers be logged, including s, face-to-face meetings, and phone calls. This high level use case address the effective tracking of communication exchanges with customers.

21 Financial Services logical data model for Social Economy based on UDM / 132 Manage Product: Before a product or service can be offered to customers it needs to be defined. This user case allows for the definition of the various services with their parameters and settings combinations. Currently this function is done mostly manually. Produce: This use case addresses the reporting needs of including queries and dashboards. Mass Mailing: Allows for the mass mailing of information to a group of customers Actors In use case modeling actors are people or systems that interact with the system in question to achieve a desired goal. Following is a list of actors as depicted in Figure 3: High Level Use Case Diagram: Local Development Fund: Customers to whom provides mostly loans to. In turn these Local Development Funds provide loans to local organizations in their jurisdiction. Some Local Development Funds are given a complete instance of the Lotus Notes application which is hosted in s environment to manage the loans they provided to their local customers. Project Manager: Person responsible for the overall management of a Project. Project Manager is a main user of the system. Analyst: Provides assistance to the Project Manager for the management of a Project. Analyst is also a main user of the system. Board of Directors: Members who oversee the activities of. Their responsibility includes the approval of loans and services provided by. They are mainly interested in having access to reports and dashboards provided by the system. Desjardins Transaction Express Service: uses Desjardins Transactions Express Service for disbursing loans and collecting payments. ( rarely deals with cash and checks). Document Management System: Allows for the storage and retrieval of electronic documents of various formats (Word, PDF, Excel, Word Pad, Power Point, Images). Currently the Document Management System (DMS) is integrated with the Lotus Notes application. Mail System: Allows for the exchange of electronic mail. Currently the Lotus Notes application has an integrated mail system. Spreadsheet application: makes extensive use of Excel for preparing payment schedules and budget plans. Lotus Notes allows for easy integration with Excel. Accounting System: Currently data from the Lotus Notes application is manually prepared and sent to the Accounting System.

22 Financial Services logical data model for Social Economy based on UDM / Overall Process New Project Process Figure 2: High Level Process Diagram shows a very high level view of the process has implemented to process requests for financial services. The following diagram provides a little more details regarding that process of a request up to the preparation of a contract. Figure 4: process flow from receipt of initial request to preparation of a contract. Once a request for financial services is received a project is created which serves to group and manage all activities related to the request from the receipt of the request for services up to the time the services are completed or closed. If the customer is new to, all its contact information is captured. Any documents related to the project that are provided by the customer or prepared by a employee are saved in s Documenting Management System (DMS) and linked to the project. An internal committee of analysts reviews the request and conducts an initial risk analysis of the request to determine if should provide the requested services. If the request is deem viable a budget plan is produce. In some cases a set of pre-condition tasks are established which are require to be completed before can provide the requested service(s). A financial risk analysis report is produced and presented to the Board of Directors for approval to provide the services. If the board approves the request a contract is prepared outlining the terms and conditions to be met by both the customer and. The following diagram is a continuation of the above flow depicting the process after a contract is prepared and signed by both parties.

23 Financial Services logical data model for Social Economy based on UDM / 132 Figure 5: process flow from signing of a contract to completion of the service. Once a contract is signed the requested service in delivered to the customer, for example in the case of a loan the requested funds are provided to the customer, through the Desjardins Transaction Express Services 10 (DTES). At predefined periods will send to DTES data requesting payments for a project. Payment data is received from DTES and updates are made accordingly in the Lotus Notes application, at the same time accounting data is prepared manually and sent to the Accounting System. On a regular basis project follow-up activities are performed and tracked including annual review of interest rates being charged to the customer. In cases where the customer is unable to pay due to bankruptcy the amount of money owed to is written-off or once the customer has completely paid for services rendered all documents associated with the project are saved into the DMS and the project is closed. 10

24 Financial Services logical data model for Social Economy based on UDM / Functional Areas and Data Subject Areas The objective of this study is to validate if the UDM can help jump start the development of the logical data model for SSFA. Given the number financial services business processes, activities and the various data needs to support these processes, a structure is required to help manage and understand the complex of areas of interest. A common approach is to group business activities and data into Functional Areas and Subject Areas. To identify the Functional Areas a simple one to one mapping of the High Level Uses Cases to Functional Area is done (see column (a) in Table 4-1: Functional Area and UDM Subject Area Scope below). In addition the key data concepts (column b) for the Functional Area are identified based on the key data needed to perform the tasks for the Functional Area. Since the objective is to develop a generic application the Functional Areas are given more generic names (column c). Finally based on the key data concepts the UDM Subject Area are identified (column d). Table 4-1: Functional Area and UDM Subject Area Scope High Level User Case /Functional Area (a) Key Data Concepts (b) Functional Area SSFA Generic Model (c) Manage Company Directory / Directory Management Society, Contact Contact Management UDM Subject Area (main ENTITY) (d) People and Organization (PARTY, PERSON, ORGANIZATION, CONTACT MECHANISM) Manage Product/ Product Management Loans, Other Financial Services Product Management Financial Product (FINANCIAL PRODUCT, FINANCIAL PRODUCT REGULATIONS AND RULES) Manage Contract /Contract Management Contract Agreement Management Financial Agreement (FINANCIAL AGREEMENT) Manage Loans and other Services Payment, Disbursement Account Management Financial Account (FINANCIAL ACCOUNT, FINANCIAL ACCOUNT TRANSACTION) Manage Loans and other Services Request for Payment Invoicing and Payment Management Invoice (INVOICE) Track Customer Communication Follow-up Log Contact Management People and Organization (COMMUNICATION EVENT) Manage Project, Analyze Risk / Project Management Project, Risk Analysis, Budget Plan, Follow-up Activity Work Effort Management Work Effort (RISK ANALYSIS, FINANCIAL PLAN, ACCOUNT NOTIFICATION)

25 Financial Services logical data model for Social Economy based on UDM / 132 Produce Reports & Mass Mailing These are not considered Functional Areas rather they are lower level activities, all information needed to conduct these activities is created in Functional Areas already identified. In Table 4-1: Functional Area and UDM Subject Area Scope column (c) and (d) provide the Functional Areas and UDM Data Subject Areas/Entities of interest, essentially defining the scope that addresses financial services requirements based on the functionality covered by s Lotus Notes application. These Functional Areas and Subject Areas serve as the initial model for SSFA. Following diagram displays the key data concepts overlaid with corresponding UDM Subject Areas as described in Table 4-1: Functional Area and UDM Subject Area Scope Figure 6: Mapping of Key Concepts to Universal Data Model Subject Areas The following diagram displays the Functional Areas and Subject Areas of interest addressed in this paper based on the scope of the Lotus Notes application for which the initial logical data model based on UDM is developed for SSFA.

26 Financial Services logical data model for Social Economy based on UDM / 132 Figure 7: SSFA Functional Areas and Subject Area The following sections of this paper describe for each Functional Area the requirements and the generic logical data models based on UDM to support the requirements and other requirements deemed essential for the Financial Services Functional Area.

27 Financial Services logical data model for Social Economy based on UDM / Contact Management Contact Management is the generic functional area name for what refers to as Directory Management. This functional area s main purpose is to allow organizations to: Record the various relationships between organizations and individuals Store and retrieve customer, partner, and any other entities of interest to the organization Keep track of customer exchanges such as phone calls, s, and letters. The subject area that supports the needs of Contact Management is known as the People and Organization subject area in UDM terminology. Since this subject area contains many entities the entities are separated into three logical data models: 1. Party 2. Contact Mechanism 3. And Communication Event. 5.1 Directory Management maintains a directory of information regarding any organization and person it has any dealings with. uses the general term Society for organizations to differentiate them from a person, who is referred to as a Contact. Besides basic information such as name and address the Directory maintains information regarding the organization s profile such as whether the organization is unionized, the type of business it is in, if the organization is a Local Development Fund, a Partner or a Government Agency Directory Management Feature List and Business Rules See Appendix Section 15.1 Directory Management Feature List and Business Rules, for descriptions of features and business rules.

28 Financial Services logical data model for Social Economy based on UDM / Directory Management Conceptual Data Model Figure 8: Directory Management Conceptual Data Model Diagram Figure 8 shows the key data concepts that support Directory Management Functional Area. refers to the organizations it deals with as Societies, the various types are: LOCAL DEVELOPMENT FUND to whom money is loan to ENTERPRISE, to whom money is loan to PARTNER FINANCIAL INSTITUTION SUPPLIER INTERNAL ORGANIZATION refers to. maintains up to the last five year of JOB STATISTICS for LOCAL DEVELOPMENT FUNDs and ENTERPRISEs. A SOCIETY must have at least one CONTACT. In some cases a specific person may be a CONTACT for more than one SOCIETY, hence the many to many relationship between SOCIETY and CONTACT. Currently the Lotus Notes application requires that a CONTACT must belong to at least one SOCIETY. ADDRESS information is maintained for the SOCIETYs and their CONTACTs. also requires a log be maintained of any s, FACE-TO-FACE MEETINGs, TELEPHONE CALLs and FAes that are exchanged with a CONTACT. In addition any documents exchanged may also be stored in the Document Management System. 5.2 People and Organization (PARTY) Logical Data Model As stated earlier Contact Management is the term chosen for Financial Services application functional area that encompasses the functionality and data requirements of Directory Management. The

29 Financial Services logical data model for Social Economy based on UDM / 132 main subject area to support this functional area is known as People and Organization in the Universal Data Model. Following diagram is the logical data model for the generic People and Organization Subject Area. The entities shown in the diagram are a subset of those that appear in the UDM, only entities deem required to support the based requirements are included in the data model. Figure 9: People and Organization PARTY logical data model diagram Those entities with a note are entities specifically added to the SSFA logical data model to satisfy requirements. Key data structures used from the UDM are PARTY, PARTY ROLE and PARTY RELATIONSHIP. PARTY is the supertype entity for subtypes PERSON and ORGANIZATION; it maintains information about a PERSON or ORGANIZATION of interest. PARTY entity exists because organizations and people require similar type of information to be stored and maintained, e.g. name, address, and phone number. A PARTY is of interest to Financial Services organization due to the assigned or required actions and activities it performs. It is common that a PARTY may perform many different activities or plays different roles. The PARTY ROLE supertype contains the common information that may exist to support the different types of roles to that a PARTY may be acting as. In the above diagram the PARTY ROLE subtypes shown are those roles which are needed to support the Contact Management Functional Area, based on the requirements. Later in this paper other PARTY ROLE subtypes will appear in LDM to support other Functional Areas e.g. OWNER, GUARANTOR, CO-OWNER.

30 Financial Services logical data model for Social Economy based on UDM / 132 In most cases the roles that a PARTY plays has to do with its relationship with another PARTY. For example in a CONTACT must belong to an ORGANIZATION, hence a PERSON has a role of CONTACT in relation to an ORGANIZATION. (In the SSFA logical data model the SOCIETY is represented by the supertype ORGANIZATION). Note: The TYPE entities contain the set of allowed types for the Entity (it contains the complete set) some which may not appear in the diagram. The PARTY TYPE data structure is for classifying the PARTY. This entity is of interest to Financial Services organizations to support the classification of client organizations based on any classification the Financial Services organization requires. A client organization may be classified for example by industry or size. In the case of they would be interested in classifying their LOCAL DEVELOPMENT FUNDS by Minority owned businesses, Women owned business or Women s shelter. Figure 10: ORGANIZATION CONTACT RELATIONSHIP logical data model diagram The above diagram shows PARTY RELATIONSHIP having a subtype of ORGANIZATION CONTACT RELATIONSHIP to model the relationship between a CONTACT and an ORGANIZATION which identifies the ORGANIZATION that a CONTACT belongs to. Also Figure 10 shows the EMPLOYMENT entity to model the relationship between an INTERNAL ORGANIZATION and EMPLOYEE. The EMPLOYMENT entity would maintain all information regarding the employee s employment for an INTERNAL ORGANIZATION.

31 Financial Services logical data model for Social Economy based on UDM / 132 Figure 11: ORG PRINCIPLE CONTACT RELATIONSHIP logical data model diagram The above diagram shows PARTY RELATIONSHIP having a subtype of ORG PRINCIPLE CONTACT RELATIONSHIP to model the relationship between a PRINCIPLE CONTACT and an ORGANIZATION which identifies the principle contact for an ORGANIZATION and would maintain any specific information regarding that relationship Mapping Key Data Concepts to UDM Entities In the SSFA logical data model the SOCIETY entity is referred to by the ORGANIZATION supertype and its subtype. The CONTACT is referred to by PARTY subtype PERSON and PARTY ROLE subtype CONTACT. The subtype entities LOCAL DEVELOPMENT FUND and ENTERPRISE of ORGANIZATION are included since the belief is that has slightly different processes depending if the CUSTOMER is a LOCAL DEVELOPMENT FUND or an ENTERPRISE. Table 5-1: Mapping Key Data Concepts to UDM Entities Entities (from Universal Data Model Conceptual Data Model) Entities Notes SOCIETY PARTY, ORGANIZATION The term SOCIETY is the same as UDM ORGANIZATION which is a subtype of PARTY. LOCAL DEVELOPMENT FUND ENTERPRISE Subtype of ORGANIZATION, CUSTOMER Subtype of ORGANIZATION LOCAL DEVELOPMENT FUND is added as a Subtype of ORGANIZATION. CUSTOMER is a subtype of PARTY ROLE. ENTERPRISE added as a Subtype of ORGANIZATION. CUSTOMER is a subtype of PARTY ROLE. CONTACT A subtype of PARTY ROLE GOVERNMENT AGENCY REGULATORY AGENCY Decided to keep the more generic UDM entity name of REGULATORY AGENCY FINANCIAL INSTITUTION Same Entity Name Subtype of ORGANIZATION. PARTNER Same Entity Name Subtype of ORGANIZATION. SUPPLIER Same Entity Name Subtype of ORGANIZATION. FINANCIAL INSTITUTION Same Entity Name Subtype of ORGANIZATION. INTERNAL ORGANIZATION Same Entity Name Subtype of ORGANIZATION.

32 Financial Services logical data model for Social Economy based on UDM / 132 EMPLOYEE Same Entity Name Subtype of PARTY ROLE. JOB STATISTICS Added to the SSFA logical data model ADDRESS CONTACT MECHANISM See Section 5.3. FACE-TO-FACE MEETING COMMUNICATION EVENT See Section 5.4. TELEPHONE CALL COMMUNICATION EVENT See Section 5.4. FA COMMUNICATION EVENT See Section PEOPLE and ORGANIZATION Entities and Attributes See Appendix Section 15.2 People and Organization Entities and Attributes, for descriptions of the entities and attributes PARTY Data Examples As one can see generic or universal data models are much more complex to understand, they would not typically be the type of models to be reviewed with business domain experts, they are intended for the software developers of an application. Following are data examples of some of the People and Organization Subject Area entities provided to help better understand the data models. Table 5-2: PARTY data example PARTY. Party ID PERSON. Last Name, First Name ORGANIZATION. Name PARTY ROLE TYPE. Role type id PARTY ROLE TYPE. Name CONTACT. Title EMPLOYEE. User ID 10 Fonds ACE 1 Customer 12 Fonds ABC 1 Customer 15 6 Internal Organization 20 YMCA 2 Partner 50 Roy, Nicole 3 Employee NRoy 33 Bureau en Gros 4 Supplier 22 Enterprise Nadia 1 Contact Meubles 13 Blais, David 4 Contact Manager 42 Martin, Ray 5 Principle Contact Director Table 5-3: PARTY RELATIONSHIP data example PARTY RELATIONSHIP TYPE. Name PARTY RELATIONSHIP. From Party (Name) PARTY RELATIONSHIP. From Role (Description) PARTY RELATIONSHIP. To Party (Name) PARTY RELATIONSHIP. To Role PARTY RELATIONSHIP. from date Partnership YMCA Partner Internal 1990/11/01 Organization Organization Blais, David Contact Fonds ACE Customer 1999/02/01 Contact Relationship Org Principle Martin, Ray Principle Contact Fonds ACE Customer 2008/01/01 Contact Relationship Employment Roy, Nicole Employee Internal 1992/01/10 Organization Customer Relationship Fond ABC Customer Internal Organization 2007/12/08 PARTY RELATIONSHIP. thru date

33 Financial Services logical data model for Social Economy based on UDM / Contact Mechanism Logical Data Model and other Financial Services organizations need to maintain PARTY information such address, various phone numbers, and addresses. The UDM refers to the various ways a person or organization can be contacted as contact mechanisms. Contact mechanism information is an important part of Contact Management. Given the different types of contact mechanism information it is not easy to model the various contact mechanisms in a consistent way. Following is the logical data model diagram modeling the contact mechanism entities and their relationships based on the UDM. Figure 12: CONTACT MECHANISM logical data model diagram Volume 3 of The Data Model Resource Book 11 series, has over 100 pages on the topic of alternative data models for contact mechanism, the author describes 4 different pattern levels for contact mechanism, Level 1 being the least flexible and Level 4 being the most flexible. The logical data model diagram above contains selected entities and their relationships based on the Level 3 and Level 4 patterns as a result of analysis done to determine what the SSFA solution targeted for the international community would require as an initial logical data model. The key data entities are CONTACT MECHANISM and GEOGRAPHIC BOUNDARY. CONTACT MECHANISM is the supertype for the different types of contact mechanisms, as shown in Figure 12, ELECTRONIC ADDRESS, TELECOM NUMBER and POSTAL ADDRESS. This model provides flexibility by allowing as many contact mechanisms as needed for a PARTY. Typically there are not many common attributes for the different types of contact mechanisms, but usually there exist many common relationships. In the Financial Services domain many types of contact mechanisms are related to entities such has PARTY, INVOICE and PAYMENT. Having a CONTACT MECHANISM supertype: 1. Helps to simplify the relationships that different contact mechanisms have to other entities 11 The Data Model Resource Book, Volume 3, Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, 2009, Wiley Publishing, Inc. [BB-3]

34 Financial Services logical data model for Social Economy based on UDM / Allows for the grouping of all contact mechanism under one supertype to manage and simplify the relationships to contact mechanisms 3. Provides a place holder for new contact mechanisms 4. Allows for a more consistent way to maintain contact mechanism data. CONTACT MECHANISM TYPE like all TYPE entities contains a list of the different classifications for the entity, e.g. Telecom Number, Electronic Address and Postal Address. Each PARTY may be contacted via one or many PARTY CONTACT MECHANISMs. A PARTY CONTACT MECHANISM maybe used for one or more CONTACT MECHANISM PURPOSEs. That is, a person or an organization may use the same telephone number for both Business and Personal use. GEOGRAPHIC BOUNDARY maintains any type of encompassing area (or jurisdiction) such as but not limited to city, province, postal code, territory, region, country. Most enterprises and their employees function within some jurisdiction that is either created by some third party, e.g. a government demarcates a region, or the organization itself defines a sales territory. Figure 13: GEOGRAPHIC BOUNDARY Subtypes shows some of the possible different GEOGRAPHIC BOUNDARY subtypes. Figure 13: GEOGRAPHIC BOUNDARY Subtypes A CONTACT MECHANISM may be referencing one or more CONTACT MECHANISM BOUNDARY which are each for a GEOGRAPHIC BOUNDARY. The GEOGRAPHIC BOUNDARY subtypes are related to each other via the GEOGRAPHIC BOUNDARY ASSOCIATION entity. Each GEOGRAPHIC BOUNDARY may be from and to other GEOGRAPHIC BOUNDARYs through the GEOGRAPHIC BOUNDARY ASSOCIATION, e.g. COUNTRY Canada contains PROVINCE Quebec, hence considered a Province Country relationship in the GEOGRAPHIC BOUNDARY ASSOCIATION TYPE entity. Another example: from the POSTAL ADDRESS one can obtain the city from the associated GEOGRAPHIC BOUNDARY and use the GEOGRAPHIC BOUNDARY ASSOCIATION to relate the city to its province ( Bellville city is related to Quebec province) the province to the country ( Quebec province is related Canada Country). See Section CONTACT MECHANISM Data Examples for more data examples CONTACT MECHANISM Entities and Attributes See Appendix Section 15.3 Contact Mechanism Entities and Attributes, for descriptions of the entities and attributes.

35 Financial Services logical data model for Social Economy based on UDM / CONTACT MECHANISM Data Examples Table 5-4: CONTACT MECHANISM PURPOSE data examples PARTY. Party ID (Party Name) PARTY CONTACT MECHANISM. Contact Mechanism ID CONTACT MECHANISM 1001 (ACE Company) 0013 (David Blais) 0013(David Blais) 0013(David Blais) 0013(David Blais) 0013(David Blais) 0013(David Blais) 0042(Martin, Ray) CONTACT MECHANISM TYPE. Description CONTACT MECHANISM PURPOSE Baker street, suite 999, the Main building New York, NY, USA, Postal Address Main Office Baker street, suite 999, the Main Postal Address Office building New York, NY, USA, ave des Pins Postal Address Home residence Telephone Number Business Mobile Number Business Mobile Number Personal 435 [email protected] Address Business rue Rose, Belville, Quebec G1R 3W4 Postal Address Office Table 5-5: CONTACT MECHANISM and GEOGRAPHIC BOUNDARY data examples CONTACT MECHANISM. Contact Mechanism ID CONTACT MECHANISM (data based on the Contact Mechanism Type CONTACT MECHANISM BOUNDARY. Geographic Boundary ID (FK) GEOGRAPHIC BOUNDARY. Name from (TYPE) GEOGRAPHIC BOUNDARY. Name To (TYPE) GEOGRAPHIC BOUNDARY ASSOCIATION TYPE. Name() Baker street, suite 999, the Main building New York, NY, USA, rue Rose, Bellville, Quebec G1R 3W rue Rose, Bellville, Quebec G1R 3W New York (City) New York (State) City State Relationship New York (State) USA (country) State Country Relationship 2222 Bellville (City) Quebec City Province (Province) Relationship 1344 Bas St-Laurent (Region) Quebec (Province) Region Province Relationship

36 Financial Services logical data model for Social Economy based on UDM / 132 Table 5-6: CONTACT MECHANISM BOUNDARY data examples Contact Mechanism Boundary ID Contact Mechanism ID Geographic Boundary ID Notes: each CONTACT MECHANISM may reference one or more CONTACT MECHANISM BOUNDARY, which are each for a GEOGRAPHIC BOUNDARY CONTACT MECHANISM (100) City of New York CONTACT MECHANISM (522) City of Bellville CONTACT MECHANISM (522) Region Bas St-Laurent Table 5-7: GEOGRAPHIC BOUNDARY ASSOCIATION data examples Geographic Boundary Association ID Geographic Boundary ID From Geographic Boundary ID To Geographic Boundary Association Type ID Notes: Relates the one Geographic Boundary to another New York city to New York State New York state to USA country Bellville city to Quebec province Quebec province to Canada country Bas St-Laurent region to Quebec province Table 5-8: GEOGRAPHIC BOUNDARY data examples Geographic Geographic Name Abbreviation Boundary ID Boundary Type id 2002 City New York N.Y. 666 State New York NY 1020 State Iowa IA 2077 City Bellville Bellville 1122 Province Quebec PQ 1133 Country Canada Canada 1233 Region Mauricie Mauricie 1344 Region Bas St-Laurent Bas St-Laurent 1155 Country United States of America U.S.A. Table 5-9: GEOGRAPHIC BOUNDARY ASSOCIATION TYPE data examples Geographic Boundary Association Type ID Name 0010 City Province Relationship 0020 City State Relationship 0030 Province Country Relationship 0040 State Country Relationship 0050 Postal Code Province Relationship 0060 Region Province Relationship

37 Financial Services logical data model for Social Economy based on UDM / Communication Event Logical Data Model Contact Management includes the tracking of any communication exchanges between PARTYs be it via , phone call, fax or face-to-face meeting a log is kept to include information like the date and time, the originator and the purpose of the communication. current Lotus Notes application allows for linking any pertinent documents to the communication exchanges to provide a complete picture the communication for later access. The Universal Data Model refers to the contact or communication exchanges between PARTYs as a COMMUNICATION EVENT Communication Event Feature List See Appendix Section 15.4 Communication Event Feature List, for descriptions of features Communication Event Logical Data Model Following is the logical data model for Communication Event Management, using UDM as the base and modified slightly to address the needs of. Figure 14: COMMUNICATION EVENT logical data model diagram The COMMUNICATION EVENT entity maintains a history of the various communications or interactions that occur within the context of each PARTY RELATIONSHIP. The reason why COMMUNICATION EVENTs are maintained within the context of PARTY RELATIONSHIPs is because it is possible have many different relationships between parties, what an organization is interested in is the communication that occurs within a specific PARTY Relationship.

38 Financial Services logical data model for Social Economy based on UDM / 132 A COMMUNICATION EVENT is used to keep a log of the following methods of communication: FA COMMUNICATION, LETTER CORRESPONDENCE, FACE TO FACE COMMUNICATION, COMMUNICATION, PHONE COMMUNICATION, and WEB SITE COMMUNICATION. Should another mode of communication be required the model can easily be extended to include it. A COMMUNICATION EVENT takes place through one and only one CONTACT MECHANISM TYPE which describes the method of communication, the event it may have many COMMUNICATION EVENT PURPOSES, like for example a meeting could be for a FOLLOW-UP and an ANNUAL REVIEW. also requires that any documents discussed or prepared as a result of a COMMUNICATION EVENT be stored in their Document Management System and linked to the COMMUNICATION EVENT. The Chair fully expects as part of the SSFA solution, it must provide an interface of some form to a Document Management System to allow for various types of documents to be linked to more than one communication event. COMMUNICATION EVENT STATUS TYPE maintains the list of valid event statuses for example: scheduled, completed, cancelled, pending and in progress. Should a series of COMMUNICATION EVENTS be required for managing a particular issue, they may be grouped under a CASE. Each CASE may have several PARTYs involved and acting in different CASE ROLEs, for example, who is responsible for the CASE and who needs to provide some form of service to assist with the CASEs. For the communication events are within the context of a PROJECT hence the relationship between PROJECT and COMMUNICATION EVENT. At a COMMUNICATION EVENT pertains to one and only one PROJECT and may generate one or more INTERNAL TASKs to successfully complete the event. Note: PROJECT and INTERNAL TASK have been added to logical data model to support requirements. See Section 10 Work Effort Management for more details regarding PROJECT and INTERNAL TASK COMMUNICATION EVENT Entities and Attributes See Appendix Section 15.5 Communication Event Entities and Attributes, for descriptions of the entities and attributes COMMUNICATION EVENT Data Examples Table 5-10: COMMUNICATION EVENT data example Communication Event ID Work Effort ID Party ID from Party ID To Date Time Started Contact Mechanism Type Status ID 778 Project11 Mario Blue David Blais :30 Phone Completed 876 Project11 Mario Blue David Blais :30 Completed 465 Project11 Mario Blue David Blais :30 Face to Face Completed 522 CONTACT MECHANISM (location) ID

39 Financial Services logical data model for Social Economy based on UDM / 132 Table 5-11: COMMUNICATION EVENT PURPOSE data example Communications Event Purpose ID Communications Event Purpose Type Communication Event ID 332 Follow up Annual Review Invite Annual Review Payment Request 778 Table 5-12: COMMUNICATION EVENT and CASE data example CASE. CASE. Case ID Description 101 Project 11 Late Payment 101 Project11 Late Payment COMMUNICATION EVENT. Communication Event ID COMMUNICATION EVENT PURPOSE.. Communication Event Purpose ID Type Follow up Request Payment Phone Follow up Request Payment CONTACT MECHANISM TYPE. Contact Mechanism Type ID 5.5 Contact Management Observations and Findings This section provides some observations, findings and insights regarding the logical data models presented for Contact Management. First some general comments regarding the data models. After reviewing the data models it becomes quickly evident that although generic models do offer flexibility, they are not easy to understand, definitely not something a non IT professional can review and validate. As stated previously, the objective of this paper is to define generic flexible logical data models that can be used as the foundation for data structures to support a family of SSFA, the models are targeted to IT professionals who will be working to develop the software for the Chair. The data models produced are based on the analysis of only one social economy Financial Services organization which is the Quebec based organization,, and the body of work described in Len Silverton s books on Universal Data Models. The Universal Data Models describe several alternative patterns to model a particular business problem. The ideal model is the simplest data model that supports all the business needs. What makes it challenging when building a generic data model for a business domain where the modeller is not a domain experts, and a full set of requirements does not exists, is what to base the decisions to model one way versus another way. For this reason these models must be viewed as starting point data models, which have has objective to allow for as much flexibility, and ability to extend the data structures given the fact that the solution application is targeted for many Financial Services social economy organizations with varying needs People and Organization An organization like does not need the complexity of entities PARTY ROLE and PARTY RELATIONSHIP. FILACTION does not currently maintain information at this level, and most likely will not need to in the future. These entities which are defined in the UDM are included in the SSFA logical data model because one can see the value in the flexibility they offer and that other Financial Services organizations may want to maintain this type of data.

40 Financial Services logical data model for Social Economy based on UDM / 132 A PARTY may play more than one role in an organization, which is the case with, an organization may play the role of a PARTNER for one PROJECT and CUSTOMER for another PROJECT, does not keep additional attributes regarding the ROLE but it is highly likely that some other Financial Services organization may need to. There are several ways to modeling a PRINCIPLE CONTACT for an organization as required by, who also requires that no more than one principle contact must exist for a Society. The choices are 1. Make CONTACT and PRINCIPLE CONTACT subtypes of PARTY ROLE and create an ORG PRINCIPLE CONTACT RELATIONSHIP to maintain information regarding the CONTACT and its ORGANIZATION. 2. Create only a CONTACT subtype entity for PARTY ROLE and include an attribute called principle contact of format Boolean, in the CONTACT entity. Method 1 makes more sense since it best describes the role of the contact as a Principle Contact, it also allows in the future for additional attributes to be included in the PRINCIPLE CONTACT entity if ever an organization wants to keep additional information regarding their principle contacts. Once again it is an issue of what are the requirements. The UDM describes additional entities such as PARTY CLASSIFICATION with its subtypes of ORGANIZATION CLASSIFICATION and PERSON CLASSIFICATION with each of these having their own subtypes like INDUSTRY CLASSIFICATION as a subtype for ORGANIZATION CLASSIFICATION. At this point there are not enough requirements to include these entities in the logical data model, hence the decision to only include the PARTY TYPE entity for classifying the PARTY. This entity allows for identifying organization based on industry or size for example in the case of they would be interested in classifying their LOCAL DEVELOPMENT FUNDS by minority owned business, woman owned business, women shelter. Suffice to say that should the business domain require more complex data structure to maintain information based on the classification of PARTY the model could easily be extended to include PARTY CLASSIFICATION entities Contact Mechanism The data model presented for CONTACT MECHANISM is fairly complex for satisfying a simple need like maintaining address information. The main advantages the CONTACT MECHANISM model presented is that it allows for the fact that there are many ways of contacting a party, and that different types of contact information is maintained in a consistent way, this should make maintaining contact data easier and allow for better data quality and easier access to data. The model is also flexible in that a new means of contact can easily be supported. Given that SSFA will need to maintain international addresses, entities from the UDM such as GEOGRAPHIC BOUNDARY and GEOGRAPHIC BOUNDARY ASSOCIATION where included in the data model. The UDM provides an even more generic CONTACT MECHANISM model, which is far more generalized and as a result more complex to understand. The model presented in this paper is a good starting point for Contact Mechanism, if after further analysis of other Financial Services organization requirements dictate that additional data structures are included the proposed model can be extended. Note: If SSFA data structures are modified or extended, after an organization has implemented SSFA, a data migration utility should be provided by the developers of the software to migrate existing data to the new data structure.

41 Financial Services logical data model for Social Economy based on UDM / 132 Through the CONTACT MECHANISM USAGE TYPE entity the model provides for the classification of the contact mechanism such as Business, Personal, Mobile, Home, Office as required by which the current application only supports a maximum 2 types of addresses for an organization. The logical data model presented does not support the formatting or address presentation which varies from country to country. The UDM provides a much more complex data model that could help to support different address presentation needs using an entity called POSTAL ADDRESS PART 12. After spending many hours analyzing the proposed UDM model it was found to be far too complex to completely understand it. The proposed UDM adds a level of complexity and flexibility that is confusing and could lead to poor implementation and eventually lead to data quality issues. Should the business need arise and one is able to justify adding such complexity including building a user interface to capture the data and the correct data structure, it is suffice to say the UDM does provide a data model for maintaining flexible international address presentation structures Communication Event The model for communication event includes the entity COMMUNICATIONS EVENT PURPOSE; requirements do not justify such an entity since it does not keep specific information on the purpose of the communication event. Replacing COMMUNICATIONS EVENT PURPOSE and COMMUNICATIONS EVENT PURPOSE TYPE with only a COMMUNICATION EVENT TYPE entity would meet the requirements; the more complex data structure was adopted to allow for flexibility. The UDM proposes a COMMUNICATION EVENT ROLE which maintains the role that each party plays during an event, e.g. caller, receiver, minute taker and facilitator. This is deemed too complex a data structure for the need, this type of information can be included in the text field attribute notes or the attribute Other Participants in the entities FACE TO FACE COMMUNICATION and PHONE COMMUNICATION. If after further analysis of other Financial Services organization the need for an EVENT ROLE entity is required the model can easily be extended. 12 Details regarding Contact Mechanism with Flexible Address Parts Pattern can be found on page 391 of The Data Model Resource Book, Volume 3, Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, 2009, Wiley Publishing, Inc. [BB-3]

42 Financial Services logical data model for Social Economy based on UDM / Financial Product Management The Financial Services industry like any other industries exists because it provides some kind of goods to potential customers. In the case of Financial Services the goods it provides are mainly services (nontangible), the services have very specific conditions and arrangements for which both the Financial Institution and the customer must abide by, if not penalties may be incurred. Product Management is the Functional Area that addresses the design, definition and cataloguing of the financial service and products offered. For a particular type of financial service, e.g. loans, there are typically different types of loan products, each designed with specific features like interest rate calculations, repayment terms, collateral requirements and in some cases even choice of currency. A financial service may be a predefined service or set of services with specific arrangements offered to many customers or a customized service (or set of services) for a specific customer. Defining the various products and their features with the different combination of parameters can be a daunting task. Developing software targeting the social economy to support Product Management is even more challenging since different Financial Services organizations support a much wider variety of services; one needs just look at the variety of services offered by the funding partners of AI2L as described in the Section 1 Introduction of this paper. This means that a financial services application must allow for highly flexible and customizable product definition, a fluid or adaptable data structure becomes an important element to support this requirement. 6.1 Financial Product Management Following is a list of the types of products/services offers to Local Development Funds and other enterprises: 1. Loans with different types of features: e.g. repayment schedules with different payment frequencies, varying grace periods, and seasonal payments (e.g. customer makes payments only during the summer months). 2. Purchasing share: where will buy shares from the Society. In this case no payment schedule is required, may charge monitoring fees and bonus fees for this service 3. Debentures: are like a loan with a payment schedule where if after a specified period the borrower is not able to pay back the loan, will purchase company shares from the customer on the remaining amount owned. 4. Revolving loan (also known as an open-end credit): a loan with a specific end date that allows the amount to be repaid and borrowed once again within specified date. also has a number of different fees it may collect from its customer: 1. Guarantee fee: example, a Local Development Fund or enterprise takes a loan from Caisse Desjardins and guarantees the loan. charges a fee for the grantee. 2. Performance fee: where charges a percentage based on the borrowers profits. 3. Late Payment fee: the borrower is charged a fee for late payments. The current Lotus Notes application does not support designing and the definition of a product and its features, this activity is done manually. The logical data model for Product Management is based on UDM and therefore needs to be validated with other social economy Financial Services organizations.

43 Financial Services logical data model for Social Economy based on UDM / Financial Product Management Feature List See Appendix Section 16.1 Product Management Feature List, for descriptions of features. 6.3 Financial Product Management Logical Data Model Figure 15: Financial Product Management logical data model diagram A Financial Services organization may offer a variety of products; these products are typically classified by PRODUCT CATEGORY. In this model only two subtypes of PRODUCT CATEGORY are show; INVESTMENT VEHICLE and LOAN PRODUCT since this represents the scope of products. Other examples of PRODUCT CATEGORY are savings, credit card and insurance. The FINANCIAL PRODUCT indicates how the services provided to the customer will behave. A FINANCIAL PRODUCT has a number of PRODUCT FEATURES and FUNCTIONAL SETTINGS that may apply when a product is defined in an agreement/contract. The FEATURE APPLICABILITY and FUNCTIONAL SETTING APPLICABILITY identify the specific features and settings that apply to the FINANCIAL PRODUCT in question. These four entities (PRODUCT FEATURES, FUNCTIONAL SETTINGS, FEATURE APPLICABILITY and FUNCTIONAL SETTING APPLICABILITY) define how a product works, allow for customizing a product offering. 6.4 Financial Product Management Entities and Attributes See Appendix Section 16.2 Product Management Entities and Attributes, for descriptions of the entities and attributes.

44 Financial Services logical data model for Social Economy based on UDM / Financial Product Management Data Examples Table 6-1: PRODUCT FEATURE and FUNCTIONAL SETTING relationship examples PRODUCT FEATURE description FUNCTIONAL SETTING description Monthly interest rate Apply interest rate at end of month Statement Prepare statement every 30 days Payment mode Electronic payment Repayment schedule Monthly payments Non sufficient funds fee Apply fee when account balance goes below zero Performance fee Apply performance fee based on borrower s annual sales profits Guarantee fee Apply fee for guaranteeing a bank loan Table 6-2 FINANCIAL PRODUCT data example FINANCIAL PRODUCT. ID FINANCIAL PRODUCT. Name PRODUCT FEATURE. Description PRODUCT FEATURE APPLICABILITY. value 11 Regular Loan Base Interest Rate Prime Interest Rate PRODUCT FEATURE APPLICABILITY. From Date Contract open date PRODUCT FEATURE APPLICABILITY. Thru Date 12 months after disbursement date Contract end date Last date on payment schedule FUNCTIONAL SETTING APPLICABILITY. Description apply interest rate at end of month 11 Fixed Interest Rate 1.5% Contract open date apply interest rate at end of month 11 Repayment 1rst date on due monthly Payment schedule 11 Grace Period 3 period to apply after disbursement 22 Revolving Base Interest Prime Interest Contract open Contract end apply interest rate at Loan Rate Rate date date end of month 22 Fixed Interest 2% Contract open Contract end apply interest rate at Rate date date end of month 22 Payment any time before end of contract The PRODUCT FUNCTIONAL SETTING APPLICABILITY indicates which FUNCTIONAL SETTINGs apply to which specific FINANCIAL PRODUCTs as part of the design of the product offering In the above example is based on two of products. For a Regular Loan a borrower is expected to make monthly payments, the interest rate is calculated based on the prime rate which is set by the Central Bank of Canada on the anniversary date of the disbursement plus a fixed interest rate set at the time of the contract and valid until the end of the contract. For a Revolving Loan the interest rate is calculated based on the prime rate plus a fixed interest rate set at the time of the contract and valid until the end of the contract. Payments (including full payment) can be made any time before the end of the contract.

45 Financial Services logical data model for Social Economy based on UDM / Financial Product Management Observations and Findings does offer a handful of products/services surrounding loans. Lotus Notes application system does not support the design and definition of the products. The products are defined manually and the software application is used in a rather crude way to identify which service is being provided to a customer. There is no doubt that a data structure is required to support the definition and maintenance of various products a Financial Services organizations may offer to its customers, the logical data model seems to provide a good starting point to allow for the support of defining various features and varying parameters in a product. More requirements and analysis are required to determine the quality and how easily the model can be implemented. The data model is quite complex since it is intended to support the complexity of business rules needed to identify which feature and which parameter setting apply for a given product. Given the complexity of the proposed UDM model and the importance of the Product Management functional area, it is strongly suggested that the Chair conduct further studies to determine if this specific functional area would greatly benefit from using a business rules engine for the definition, maintenance and applicability of product business rules. 6.6 Financial Product Regulations and Rules Management Analysis of current system has not expressed a need for a Product Regulations and Rules logical data model. The belief is that since the open source software that the Chair will be developing is targeting the international market, and since the Financial Industry is highly regulated, in most countries, there will be a set of governmental, or standards body with regulations and rules that the Financial Services organizations which need to abide by. It is expected these regulations and rules will impact how a financial product will function, and what may and may not be offered as a product or service. The Universal Data Models includes a very generic model for Financial Products Regulation and Rules 13, which may be useful for the chair to consider once the requirements for financial product regulations and rules are better understood. The model has also been included in this paper to show the relationship between the financial product regulations and rules and the entities FINANCIAL PRODUCT, PRODUCT FEATURE and PRODUCT SETTING described in section 6.3 Financial Product Management Logical Data Model. Financial Products Regulation and Rules consists of regulation requirements that a financial services organization needs to follow. These regulation requirements affect what features and functional settings may be available for a financial product, and dictate what FUNCTIONAL SETTING APPLICABILITY or PRODUCT APPLICABILITY may be applied to FINANCIAL PRODUCTS. 13 Page 273 The Data Model Resource Book, Volume 3, Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, 2009, Wiley Publishing, Inc. [BB-3]

46 Financial Services logical data model for Social Economy based on UDM / Financial Product Regulations and Rules Management Logical Data Model Figure 16: Financial Product Regulations and Rules Management logical data model diagram 14 REGULATION REQUIREMENTS are the statements of understanding of what the Financial Services organization needs to follow. A FINANCIAL REGULATION may be a requirement governed by external agencies or the Financial Services organization itself. The model shows two subtypes for FINANCIAL REGULATION: GOVERNMENT REGULATION: are external regulation imposed by different levels of governmental bodies (e.g. federal, state and local bodies). ORGANIZATION REGULATION: are defined by the financial services organization and enforced by management. FINANCIAL REGULATIONs and associated REGULATION REQUIREMENTs impose FINANCIAL PRODUCT RULEs that impact FINANCIAL PRODUCTs, PRODUCT FEATUREs and/or FUNCTIONAL SETTINGS. AGREEMENT TERMS that were negotiated with customers may also impose FINANCIAL PRODUCT RULES that affect the same entities. See Section 7 Financial Agreement Management. 6.8 Financial Product Regulations and Rules Management Entities and Attributes See Appendix Section 16.3 Financial Product Regulations and Rules Management Entities and Attributes, for descriptions of the entities and attributes. 14 Source: p 274, Figure 6.4 Financial product regulations and rules. The Data Model Resource Book, Volume 3, Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, 2009, Wiley Publishing, Inc. [BB-3]

47 Financial Services logical data model for Social Economy based on UDM / FINANCIAL PRODUCT RULE Data Example Table 6-3: FINANCIAL PRODUCT RULES data example REGULATION REQUIREMENT AGREEMENT TERM FINANCIAL PRODUCT RULE. Description Statements cannot be ed to customers Statements for all saving or investmentoriented products must be sent at least once a year Enforce that statements are not e- mailed Ensure that deposits product statements are sent at least once a year Ensure that investment vehicle statements are sent at least once a year PRODUCT CATEGORY. Description Deposit product Investment vehicle PRODUCT FEATURE. Description Statement Statement FUNCTIONAL SETTING. Description Statement is to be sent very year 6.9 Financial Product Regulations and Rules Management Observations and Findings This logical data model is not based on any requirements from. The logical data model is included for information purposes and based on speculation that a Financial Services software solution such as SSFA would require such a data structure to support the management of varying regulations and rules, especially in light of difference in international standards. This model may allow for grouping and simplify the maintenance of regulations and rules by international bodies that a Financial Services organization need to abide by.

48 Financial Services logical data model for Social Economy based on UDM / Financial Agreement Management For a customer to receive services from a Financial Services organization the customer starts by making a request in some form. Once the request is approved by the Financial Services organization an agreement between both the Financial Services organization and the customer is prepared. Once the agreement is accepted by both parties, the agreed upon product or service is established by the Financial Institution and the customer is given access to the service. As there are different types of products that a Financial Services organization may offer, with varying features and settings the main purpose of Financial Agreement Management is to specify all pertinent information about the product or service a customer is requesting including the agreed upon product features and setting, the conditions and terms that each party must abide to for the provisioning by the service. uses the term Contract, for the SSFA model the more generic UDM term Agreement is adopted. Note: The agreement process may take on many forms, for example a process where a complete review and analysis of the customer request is prepared for approval by a Board of Directors to a simple click of an I agree button on a web page. 7.1 Contract Management While for most Financial Services organization typically the agreement process starts with a customer applying for an ACCOUNT, at a request for any service starts with the opening of a PROJECT. has pre-established contracts for the Local Development Funds, these are managed manually. The Local Development Funds who in turn provide loans to their local organizations require that a formal contract be prepared. In some cases a employee actually manages and maintains those contracts that the Local Development Funds makes with their local organizations in the Local Development Funds instance of Lotus Notes application that runs in the environment. For other enterprises requesting services from a contract is captured and prepared through their Lotus Notes application Contract Management Feature List and Business Rules See Appendix Section 17.1 Contract Management Feature List and Business Rules, for descriptions of features and business rules.

49 Financial Services logical data model for Social Economy based on UDM / Financial Agreement Management Logical Data Model Figure 17: Financial Agreement Management logical data model diagram A Financial Services organization would have different types of FINANCIAL AGREEMENTs depending on the FINANCIAL PRODUCTs and services it provides. LOAN AGREEMENT and INVESTMENT AGREEMENT shown in the above diagram are different types of FINANCIAL AGREEMENTs prepared by. An AGREEMENT is composed of many AGREEMENT ITEMs and AGREEMENT TERMs which may further defined by many AGREEMENT ITEMs. AGREEMENT TERMs may be categorized by variety of types like: FINANCIAL, LEGAL, INCENTIVE, and OTHER AGREEMENT TERMs, as described by the AGREEMENT TERM TYPE entity. There may be several PARTYs involved in the application for products or services, each playing different roles, this is captured through the AGREEMENT ROLE and AGREEMENT ROLE TYPE entities. In the case of a FINANCIAL AGREEMENT is also linked to a PROJECT which groups all activities and information regarding a product or service provided to a customer under the PROJECT, for management purposes. Lastly for some FINANCIAL PRODUCTs, declaration of ASSETs is required. Since each PARTY would have different involvement with an ASSET, e.g. Partially owned or Fully owned the ASSET ROLE is required to capture this information. 7.3 Financial Agreement Management Entities and Attributes See Appendix Section 17.2 Financial Agreement Management Entities and Attributes, for descriptions of the entities and attributes.

50 Financial Services logical data model for Social Economy based on UDM / Financial Agreement Management Observations and Findings The logical data model seems flexible enough to satisfy the basic needs of Financial Services organizations for financial agreements. The Financial Services organization specific requirement to address agreed upon conditions for product and services would be handled by the entities PRODUCT FEATURE, FUNCTIONAL SETTING, and AGREEMENT ITEM entities. The FINANCIAL AGREEMENT groups the agreed upon features into one place, i.e. an agreement or a contract. This model has strong links to the data for the Product Management Functional Area, since it references FINANCIAL PRODUCTs and their applicable features. As with all the models present this paper more requirements from other Financial Services organizations are required to validate the model. Items that come to mind that require further analysis are: Whether an Agreement should be divided into sections The print formatting of an Agreement In cases where an agreement is modified is there need for an ADDENDUM type entity The integration of Agreement Management with a Document Management System More analysis is required to complete the attributes needed for AGREEMENT TERM.

51 Financial Services logical data model for Social Economy based on UDM / Account Management Typically Financial Services organizations provide services to its customers are through an account, once an agreement has been signed. The account is used to keep track of all the financial transactions or events performed by the Financial Services organization and the customer in relation to the agreed upon financial product. Account Management includes the following functions: Creation of a Account Tracking of Account Transactions. 8.1 Account Management creates a Project instead of an account to monitor all transactions and events performed for a product/service it provides. The Project is very similar to an account except it also links to additional information like budgets and communication events. uses the account services of Caisses Desjardins du Québec (aka Desjardins), known as Desjardins Transaction Express Service (DTES). does not directly handle customer accounts; Desjardins establishes an account for a project. maintains in its Lotus Notes application a history of transactions events that occurred against the account. prepares and sends the information regarding payments required to Desjardins. The customer makes payments to the Desjardins account. Desjardins then sends information regarding customer payments to. The advantage of this service is that does not need to handle any cash money or checks; this is left up to Desjardins to do. The advantage to the customer is that he/she can withdraw or deposit money online or from the various Desjardins branches located throughout Quebec Account Management Feature List and Business Rules See Appendix Section 18.1 Account Management Feature List and Business Rules, for descriptions of features and business rules.

52 Financial Services logical data model for Social Economy based on UDM / Account Management Logical Data Model Figure 18: Account Management logical data model diagram An ACCOUNT may have one or more PARTYs involved, where each PARTY plays different ACCOUNT ROLES, e.g. OWNER, JOINT-OWNER, GUARANTOR. An ACCOUNT is established once an AGREEMENT is reached between the Financial Services organization and PARTYs. The above model shows only LOAN ACCOUNT, INVESTMENT VEHICLE ACCOUNT and OTHER ACCOUNT types of accounts, since these are the types supported by. The types of ACCOUNTs are determined by the FINANCIAL PRODUCTs and services offered by the Financial Services organization. OTHER ACCOUNT in this model has been defined to allow for the monitoring of payments for fees like Performance fees and Guarantee fees. There may be cases where an ACCOUNT may include more than one FINANCIAL PRODUCT, hence the one to many relationship between ACCOUNT and ACCOUNT PRODUCT. 8.3 Account Management Entities and Attributes See Appendix Section 18.2 Account Management Entities and Attributes, for descriptions of the entities and attributes.

53 Financial Services logical data model for Social Economy based on UDM / Account Transaction Management Logical Data Model Figure 19: Account Transaction Management logical data model diagram As stated previously an ACCOUNT records of all activity or transactions that PARTY(s) or a Financial Services organization has performed in relation to the use of a service (FINANCIAL PRODUCT). The ACCOUNT TRANSACTION is what is generated each time there is activity against an ACCOUNT. There are basically two types of activities that take place against an ACCOUNT: 1. Monetary FINANCIAL TRANSACTIONs, e.g. ACCOUNT PAYMENTs, WITHDRAWALs, DEPOSITs, INTERESTs ACCOUNT FEEs, and SECURITY TRANSACTIONs to buy and sell securities. 2. Non monetary ACCOUNT REQUEST TRANSACTIONs, e.g. customer INQUIRY REQUESTs, SPECIAL REQUESTs and CHANGE REQUESTs. ACCOUNT TRANSACTION STATUS tracks transactions status from the time they enter the system right through completion. ACCOUNT TRANSACTION TASKs are activities or transactions that occur once or at regular time intervals as specified by TIME FREQUENCY. Examples of ACCOUNT TRANSACTION TASKs are: 1. POST TRANSACTION TASK: monetary transactions that cause an ACCOUNT credit or debit 2. AUTHORIZED TRANSACTION TASK: monetary transactions that occur as authorized by the customer 3. PRE-DETERMINE TRANSACTION TASK: pre-established transactions that occur at specific times (e.g. monthly, weekly). The ACCOUNT TRANSACTION TASK entity is specifically designed for automating functions to ensure ACCOUNT activities are executed in a timely fashion.

54 Financial Services logical data model for Social Economy based on UDM / Account Transaction Management Entities and Attributes See Appendix Section Account Transaction Management Entities and Attributes, for descriptions of the entities and attributes ACCOUNT TRANSACTION Data Examples Table 8-1: ACCOUNT TRANSACTION data example ACCOUNT TRANSACTION. ID ACCOUNT TRANSACTION TYPE. Description ACCOUNT. ID ACCOUNT. Description Account Payment Deposit 3333 Savings Account ACCOUNT TRANSACTION. Entry Date ACCOUNT TRANSACTION. Amount 2222 Loan Account Posted Posted ACCOUNT TRANSACTION STATUS. Description Table 8-2: ACCOUNT TRANSACTION TASK data example ACCOUNT TRANSACTION TASK. ID ACCOUNT TRANSACTION TASK (Subtype) ACCOUNT. ID ACCOUNT TRANSACTION TYPE ACCOUNT TRANSACTION. Amount ACCOUNT TRANSACTION TASK. Creation Date ACCOUNT TRANSACTION TASK. Requested Date 4343 Pre-determined 3333 Withdraw Pre-determined 2222 Account Fee Account Management Observations and Findings Because uses Desjardins Transaction Express Service, minimal requirements could be extracted from the Lotus Notes application User Guides, the logical data model presented for account transaction management is completely a UDM construct. From the time a transaction enters the system there are a number of different validations that need to occur against the transition and as a result there are many processing routes the transaction may take, e.g. a transaction finds insufficient fund or errors causing it to fail or it may be rejected for some reason. Given the numerous conditions that may arise when processing a financial transaction and the complexity of the business rules to process the transaction, this makes financial transaction processing a candidate for a business rules engine solution.

55 Financial Services logical data model for Social Economy based on UDM / Invoicing and Payment Management Financial Service organizations send an invoice to customers requesting payment for products or services provided, example for a loan that is due or active, an invoice is issued as per the payment schedule agreed upon at the time the agreement/contract was establish. Once the payment is received it is applied to an ACCOUNT. A Financial Service organization depending of the products and services it offers may also periodically send to customers a statements which provides a view of the state of an account and the history of all transactions that occurred within a period, including balances, fees, paid and charged interest. Note: INVOICE and STATEMENT are subtypes of ACCOUNT NOTIFICATION; see Section 10.3 Work Effort (Account Notification) Management Logical Data Model. 9.1 Billing and Payment Processing only issues invoice it does not issue any statements to its customers. Since uses Desjardins Transaction Express Services, it prepares payment requests for each project at the beginning of each month for payments to be received for the complete month and sends the information to Desjardins Transact Express Services. As customers make their payments Desjardins sends the payment information to reconciles the payment received with the payment due in their Lotus Notes application against the project. An invoice may contain multiple items, for example, applicable fees and loan principle and interest due Billing and Payment Processing Feature List and Business Rules See Appendix Section 20.1 Billing and Payment Processing Feature List and Business Rules, for descriptions of features and business rules.

56 Financial Services logical data model for Social Economy based on UDM / Invoicing and Payment Management Logical Data Model Figure 20: Invoicing and Payment Management logical data model diagram A Financial Services organization will receive an ACCOUNT PAYMENT and DEPOSIT the RECEIPT into an ACCOUNT An INVOICE may be composed of many INVOICE ITEMs showing the detailed information for products or services, for example for a loan product the items on an invoice would be for the principle amount due, interest due and fees due. An INVOICE ITEM for each of these charges would be included as part of the INVOICE. Each INVOICE ITEM is the charge for a PRODUCT FEATURE as agreed upon at the time the ACCOUNT was established. Each INVOICE may be categorized by an INVOICE TYPE, which would include values such as Loan Invoice, Loan Invoice Adjustment. Guarantee Fee Invoice An INVOICE state changes over time, examples of invoice status are sent, void, on hold, hence the need for an INVOICE STATUS entity. A PAYMENT may be made via several methods as describe by the PAYMENT METHOD TYPE, e.g.: Electronic, Personal check, Cash. A PAYMENT is applied to an ACCOUNT through PAYMENT APPLICATION, as well as the INVOICE ITEM. Financial Services organizations usually receive partial payments, relating PAYMENT APPLICATION to an INVOICE ITEM allows a Financial Services organization to track the payment of each INVOICE ITEM. Especially important for when partial payment is received, business rules determine which invoice item is paid off first. At the order to apply payments for loans is first to fees due, then interest due and lastly principle. Each PAYMENT may be either a RECEIPT or a DISBURSEMENT, which is linked to different types of FINANCIAL TRANSACTION (i.e. DEPOSIT and WITHDRAWAL). One or more RECEIPTS could be included in a DEPOSIT.

57 Financial Services logical data model for Social Economy based on UDM / 132 Each DISBURSEMENT may be related to a customer WITHDRAWAL, which is a type of FINANCIAL ACCOUNT TRANSACTION that affects a FINANCIAL ACCOUNT. 9.3 Invoicing and Payment Management Entities and Attributes See Appendix Section 20.2 Invoicing and Payment Management Entities and Attributes, for descriptions of the entities and attributes. 9.4 Invoicing and Payment Management Observations and Findings The logical data model presented for Invoicing and Payment Management is basically the UDM, and based on the current understanding of this Functional Area. The logical data model at this initial stage is not very complex. It is expected that further analysis of this Functional Area will produce many business rules and identify dependencies and coordination required between activities to manage incoming and outgoing payments, which would make it a good candidate for Business Rules Engine and possibly a Process Flow Engine since the management of these activities will vary from one Financial Services organization to another.

58 Financial Services logical data model for Social Economy based on UDM / Work Effort Management There are a number of activities a Financial Services organization must perform, besides tracking account transactions that are required to efficiently manage the services they provide to customers. Most of these activities are ongoing activities that have to do with keeping the customer informed on the status of their accounts (e.g. the periodic preparation of invoices and statements), providing customer assistance on any issue that may arise, and notifying them of potential improvements to the level of service being provided. The UDM groups these activities under a subject area called Work Effort. A work effort is the fulfillment of the work requirement. This includes setting up and planning for the actual work that will be performed, as well as recording the status and information related to the efforts and tasks that are taking place. 15 This functional area includes the following functions: Account Notification Risk Analysis Financial Planning Project Management uses the concept of a PROJECT to group all activities required to effectively manage a service provided to their customers, from the initial request for a service right through the completion or closing of a service. A PROJECT is established for each new service provided by to a customer. The PROJECT provides links to the following type of information: Customer initial request for service Risk Analysis results Contract / Agreement information Request for payments Account information, remember uses Desjardins Transaction Express Services for handling any payments or disbursements made against the account Society s budget plan for the initiative the society has undertaken and thus needs a loan or other services from All communication exchanges (phone calls, meetings and s) held with the customer and links to documents exchanged Follow-up / monitoring activities e.g. meeting for an annual rate review, tracking of an internal request for assistance on a project. The following table shows where the above information managed by a PROJECT is stored in the Universal Data Models. Table 10-1: Mapping Project Management information to UDM Subject Areas Project Management information Subject Area (Main Entity) Sections in this paper where details are provided Customer initial request for service Work Effort See Section 10 Work Effort Management 15 page 186 The Data Model Resource Book, Volume 1, A Library of Universal Data Models for all Enterprises, by Len Silverston, 2001, John Wiley & Sons, Inc. [BB-1]

59 Financial Services logical data model for Social Economy based on UDM / 132 Risk Analysis results Contract / Agreement information Work Effort (RISK ANALYSIS OUTCOME) Financial Agreement See Section 10 Work Effort Management See Section 7 Financial Agreement Management Request for payment Invoice See Section 9 Invoicing and Payment Management Account information including payments or disbursements made against the account Society s budget plan for the initiative the Society has undertaken an thus needs a loan or other services from communication exchanges Documents exchanged Follow-up/ monitory activities Planning and follow-up of Internal activities Financial Account (FINANCIAL ACCOUNT, FINANCIAL ACCOUNT TRANSACTION) Work Effort (FINANCIAL PLAN) People and Organization (COMMUNICATION EVENT) Not applicable Work Effort (ACCOUNT NOTIFICATION) Work Effort (ACCOUNT NOTIFICATION, INTERNAL TASK) See section 8 Account Management See Section 10 Work Effort Management See Section 5 Contact Management See Section 10 Work Effort Management See Section 10 Work Effort Management As indicated in the above table Subject Areas that address other entities other than WORK EFFORT are address in other sections of this paper. The Chair understands that Financial Services organizations may need a Document Management System (DMS) to store, control, track, and provide easy access to electronic documents or images of paper documents and is addressing the solution for this requirement through a separate initiative Project Management Feature List and Business Rules See Appendix Section 19.1 Project Management Feature List and Business Rules, for descriptions of features.

60 Financial Services logical data model for Social Economy based on UDM / Work Effort (Account Notification) Management Logical Data Model Figure 21: Work Effort (Account Notification) Management logical data model diagram In the UDM the WORK EFFORT entity is the supertype for all activities that require resources and have start and end dates. The above models shows UDM extensions for the WORK EFFORT Subject Area to include NOTIFICATION TASKs required to efficiently manage the services provided to a customer. ACCOUNT NOTIFICATIONs are directly related to an ACCOUNT or PROJECT and may result in the preparation of outputs such as an INVOICE or a STATEMENT. A NOTIFICATION TASK may generate one or more ACCOUNT NOTIFICATION(s). But an ACCOUNT NOTIFICATION may not necessarily be generated by a NOTIFICATION TASK. As a result of the analysis done regarding needs the entity INTERNAL TASK is added to the model to extend the NOTIFICATION TASK. INTERNAL TASKs would work the same as the other tasks except an INTERNAL TASK is directed to employees of the Financial Services organization instead of a customer. Other subtypes of NOTIFICATION TASK are: INVOICING TASK: for events associated with the process of notifying the customer of the amount due on an ACCOUNT. STATEMENT TASK: for events associated with the process of notify the customer of the account status and activities performed against the account. ALERT TASK: an event that notifies the customer of any possible problem or issue with the account, e.g. an account transaction error is found, suspected fraud on the account. MARKETING TASK: an event associated with the process of notifying the customer of possible opportunities to improve their service, e.g. solicitation for new products not currently used by the customer. OTHER NOTIFICATION TASK: An event that requires the Financial Services organization to contact a customer for purposes other than invoicing, statements, alerts or marketing, e.g. notification for payments that are past due or changes to the service on the account.

61 Financial Services logical data model for Social Economy based on UDM / 132 Note the above NOTIFICATION TASKs subtypes are performed according to the settings/guidelines establish in the PRODUCT FEATURE s and FUNCTIONAL SETTINGs for the ACCOUNT PRODUCT (see Section 6 Financial Product Management), in accordance with the agreement made with the customer Work Effort (Account Notification) Management Entities and Attributes See Appendix Section 19.2 Work Effort (Account Notification) Management Entities and Attributes for descriptions of the entities and attributes Risk Analysis Risk Analysis conducts a risk analysis of all new projects to determine the viability for potential loss within a credit exposure. also conducts a risk analysis on the anniversary of the loan disbursement date, and updates the updates the project risk score (a simple text field) which is reported to the Board of Directors Risk Analysis Feature List See Appendix Section 19.3 Risk Analysis Feature List, for descriptions of features.

62 Financial Services logical data model for Social Economy based on UDM / Risk Analysis Logical Data Model Figure 22: Risk Analysis logical data model diagram The model in Figure 22 supports the capturing of information regarding risk analysis activities and results. A Financial Services organization conducts a RISK ANALYSIS on an RISK ANALYSIS SUBJECT, which could be either an ACCOUNT, a PARTY or as in the case of for a PROJECT. Note: RISK ANALYSIS SUBJECT is not an entity in the UDM it was created to allow for a simplified version of the UDM proposed model. For a RISK ANALYSIS a Financial Services organization may collect and analyze data concerning a number of different risk ANALYSIS PARAMETERs to determine the level of risk. Examples of such PARAMETERS are: For a loan an analysis of the credit risk, which is the likelihood that a borrower will default (late payments or declare bankruptcy) on a loan. For cases where a Financial Services organization purchases shares, a liquidity risk, which would investigate likelihood that for a given security or asset it could not be traded quickly enough to prevent a loss or to obtain the desired profits. Once the RISK ANALYSIS activity is completed the result of the analysis of the parameters are stored in the ANALYSIS OUTCOME Risk Analysis Entities and Attributes See Appendix Section 19.4 Risk Analysis Entities and Attributes, for descriptions of the entities and attributes.

63 Financial Services logical data model for Social Economy based on UDM / Risk Analysis Data Example Table 10-2: RISK ANALYSIS data example 16 RISK ANALYSIS. Name ANALYSIS PARAMETER TYPE Determine viability of loan credit risk ANALYSIS PARAMETER. weight ANALYSIS OUTCOME. score RISK ANALYSIS SUBJECT. score PARTY. Name Credit history (good) AA Fonds ACE Repayment behaviour (good) Debt amount ( ) Risk Analysis Observations and Findings The Risk Analysis model presented is a subset of the UDM Analysis Task model, with the introduction of the RISK ANALYSIS SUBJECT and RISK ANALYSIS SUBJECT TYPE entities to allow for a simpler data model to support the fact the a risk analysis can be performed for an organization, a party or as in the case of a project. This data model surpasses the requirement needs of, allowing for the capturing of the various RISK PARAMETERs and their values to support the ANALYSIS OUTCOME score. The model is simple and is believed to more than adequately support the needs of most Financial Services organizations Budget Planning As part of managing their Projects requires that a budget plan is prepared by the project managers for a loan project. The main reason customers request loans is to fund an activity required for the success of their business. The budget plan provides a complete view of the business activity the customer needs the loan for. The budget plans contains planned and actual views of expenses and funding required for the business activity in question. The information provided in the budget plan is an important source of input in the Board of Directors decision to approve a loan. Following is the type of information provided in the budget plan prepared by with their customer: Expenses (Planned and Actual): o Tangible o Intangible o Working capital o Other. Financing (Planned and Actual): o Donations and grants o Loans o Equity and quasi equity o Intake and internal capitalization o portion of the funding o Cooperative financing funds. Note: For the SSFA logical data model the more generic term Financial Plan is used instead of Budget plan. 16 Modified Table 6.18 Analysis Task Credit Score from page 299, The Data Model Resource Book, Volume 2, A Library of Universal Data Models by Industry Types, by Len Silverston, 2001, John Wiley & Sons, Inc. [BB-2]

64 Financial Services logical data model for Social Economy based on UDM / Budget Planning Feature List and Business Rules See Appendix Section 19.5 Budget Plan Feature List, for descriptions of features and business rules Financial Plan Logical Data Model Figure 23: Financial Plan logical data model diagram The above model was created specifically to address the requirement to maintain a budget for its PROJECTs. It is believed that other Financial Services organization in the Social Economy will have similar needs, where they will want to a view of the customers plans to accomplish their objectives. A FINANCIAL PLAN may be prepared for a Project. The FINANCIAL PLAN outlines the EPENSES and FINANCING details to support the PARTY s objective for the PROJECT. FINANCIAL PLAN TYPE provides the classification for the types of line items that would be included in the FINANCIAL PLAN, the values being Expense and Financing. The FINANCIAL PLAN STATUS TYPE provides the classification to identify if the FINANCIAL PLAN is of type Plan or Actual Financial Plan Entities and Attributes See Appendix Section 19.5 Financial Plan Entities and Attributes, for descriptions of the entities and attributes Work Effort Observations and Findings Financial Services account notification processes with all its activities and business rules required to coordinate tasks and associate notifications can become very complex. This functional area is about the management of a series of activities required to be performed at specific times by one or more individuals. The data model is there to support the automation of the planning and managing of the

65 Financial Services logical data model for Social Economy based on UDM / 132 various activities/tasks. It is believed that for these reasons a good solution for this functional area could be a process flow engine. The UDM describes a set of entities for financial objectives, needs and plans, geared mostly to meet the requirement of identifying a customer s objectives and recommending which products the Financial Services organization can offer to meet those objectives. This is not quite the same as the requirement for a Project budget plan hence a specific model was developed which needs to be validated against the requirement of other Financial Services organization before it can be considered a generic model for SSFA.

66 Financial Services logical data model for Social Economy based on UDM / Findings The objective of this paper is to investigate if the Universal Data Models proposed by Len Silverston can be used as a starting point for developing the data structures required to support the varying needs of social economy Financial Services organizations. This section sets out to show that the UDM proved to be extremely helpful to jumpstart logical data modeling activities for SSFA. Through the reuse of the Universal Data Models as a base model, or adapting UDM patterns SSFA has a good quality initial generic data model that can support the financial services needs of and provides the flexibility to begin to address the needs of other social economy organizations Universal Data Model support for Requirements After conducting an analysis of s requirements by reviewing a couple of User Guides of their current Lotus Notes application and using these requirements to validate if the UDM supports the requirements it was found that the UDM do in fact save time and effort by leverage on the reuse of these models. Also important is that by reviewing and analyzing the Universal Data Models and the explanations behind the models, the pros and cons of alternative models do give rise to inquire and explore other possible information requirements that one may not have thought of, especially if the data modeller is not an expert in the business domain being analyzed. With limited business requirements and a few short meetings with the business analyst a broad encompassing logical data model is produced for SSFA. It is an initial data model to be used has a starting point to proactively inquire, validate and explore for more information requirements from other Financial Services organizations in the social economy. In the case of the Contact Management Functional Area, it is believed that the Chair has enough requirements and a stable, flexible logical data model that can be used to initiate prototyping activities. The prototype will help to evaluate the effort required to implement the SSFA Contact Management Functional Area and its data model. The prototype will also allow for the evaluation of other Chair design decisions and obtain early feedback to elicit additional requirements for the Functional Area. There is no specific method used to arrive at deciding which UDM entities and relationships to adopt to include into the SSFA logical data model. The decision to include certain entities and relationships is based on the understanding of the requirements, inferring what other Financial Services organizations may have as requirements and the desire to keep the data model as simple as possible. The result is an overall initial logical data model which addresses the main SSFA Functional Areas. The table in Appendix Section 21 Appendix G - Mapping of SSFA entities to Universal Data Model Entities, illustrates for each Subject Area, which UDM entities were adopted and included the SSFA logical data model. As one will note very few new entities were added to the UDM to satisfy requirements, suggesting that UDM provides a fairly holistic data model General Criteria for Evaluating a Data Model A data model constitutes only part of an overall system specification, but it does have a very high impact on the overall quality and maintainability of a system. Data is a valuable asset to the business (especially true in the Financial Services sector); poor or inaccurate data reduces the value of the data and usually has very negative impact on the business. A data model is key to achieving good quality data, it

67 Financial Services logical data model for Social Economy based on UDM / 132 establishes a common understanding of the data, identifies how to interpret the entities, attributes and relationships which eventually are implemented into physical data base tables and columns. The question becomes when the ratio of available requirements to work with is very low in terms the requirements of the overall system how does one evaluate the quality of a data model. In the book Data Modeling Essentials 17 [BB-4], some general criteria are specified to help evaluate how well a data model supports the design and the development of effective systems. The following table lists those general criteria and evaluates them against the SSFA logical data model, the column Meets Criteria refers to whether the SSFA logical data model meets the criteria. Table 11-1: General Criteria for Evaluating a Data Model 18 Criteria Description Meets Criteria Completeness The data model must meet all the NO necessary data requirements. Evaluation Notes The Chair does not have all the requirements and most likely never will. Non-redundancy The same fact should not appear in more than one entity, to do so leads to consistency problems. YES The LDM proposed do not have any redundancy. Enforcement of Business Rules A data model allows for the enforcement of some business rules, resulting in a physical database to enforce correct practice and maintain data quality. NO Since the objective is to construct generic or generalized data models the proposed model limits the enforcement of business rules. On the flip side any misrepresentation of business rules in a data model may make it very difficult to correct later or to code around. Data Reusability Data that is reusable for purposes beyond the anticipated needs at design time increases its asset value factor. To increase data reusability a data model needs to be analyzed, modeled and structured independently of any specific application. YES The SSFA logical data models are the result of reusing UDM, which inherently were developed for data re-use. Stability and Flexibility A stable data model means the model remains stable in the face of changing requirements. A flexible data model means it can YES This is the main objective of the Universal Data Models which the SSFA logical data model is based on. 17 Data Modeling Essentials Third Edition, by Graeme C. Simsion and Graham C. Witt, 2005, Elsevier Inc. [BB-4] 18 Descriptions adapted from pages 10-15, Data Modeling Essentials Third Edition, by Graeme C. Simsion and Graham C. Witt, 2005, Elsevier Inc. [BB-4]

68 Financial Services logical data model for Social Economy based on UDM / 132 be readily extended to accommodate likely new requirements with only minimal impact on the existing structure or simple extensions suffice. Elegance A data model: Provides reasonably neat and simple classification of the data Is consistent with other models covering the same scope Is documented and can be easily summarized. YES The SSFA logical data model is consistent, documented and provides for the known (to date) requirements. The model does allow for changes in the classification of data. Believe it will not be a problem to summarize or produce higher level data models depending on the level of abstraction needed to effectively communicate. Communication Entities represent business concepts that the users and business specialists are familiar with and can easily verify. Supports communication among the various stakeholders in the design of a system including programmers. NO The models introduce new concepts, are generalizes and abstract, stable and elegant but difficult for non-it professionals and less experienced developers to grasp or completely understand. Out of the seven criteria three are not met by the proposed logical data model: Completeness, Enforcement of business rules and Communication. These three are all a direct result of the Chair s objective to develop a generic/generalized data model since the software solution is targeting a wide variety of Financial Services organization with various requirements and business rules, which are not available at this time. Based on the above evaluation one can conclude that the proposed SSFA logical data model, which admittedly is still in its initial stage, is good quality data model.

69 Financial Services logical data model for Social Economy based on UDM / Summary of Findings by Functional Area Given that a number of observations and findings are documented in various sections of this paper the following table summarises those observations and findings by Functional Area. Table 11-2: Summary of Findings by Functional Area High Level Use Case /Functional Area Functional Areas for SSFA UDM Subject Area (main ENTITY) Main Findings regarding the proposed SSFA logical data model (which is based on the UDM) Manage Company Directory / Directory Management Track Customer Communication Contact Management Contact Management People and Organization (PARTY, PERSON, ORGANIZATION, CONTACT MECHANISM) People and Organization (COMMUNICATION EVENT) Very flexible model that supports all of s requirements, plus allows for managing new and changing roles and for maintaining information about the different types of roles. Model could be difficult for non IT professionals to understand. Proposed data model for postal address quite complex, need to further asses what the true requirements are to determine the level of complexity needed for the SSFA LDM. Manage Product/ Product Management Product Management Financial Product (FINANCIAL PRODUCT, FINANCIAL PRODUCT REGULATIONS AND RULES) Functional Area lacks requirements from. Proposed model allows for the definition of the various product features and settings and their applicability to products and services provided. Model is complicated to understand and believe IT professionals will also have some difficulty understanding and maintaining it. Recommend that for this Functional Area investigate further the use of a business rules engine to simplify the maintenance of business rules. Manage Contract /Contract Management Agreement Management Financial Agreement (FINANCIAL AGREEMENT) Functional Area lacks requirements from. Like the fact that the proposed model links the Agreement to the Product features and settings. The main data attributes in this model are text data; need to investigate how this data model could be linked to a Document Management System.

70 Financial Services logical data model for Social Economy based on UDM / 132 Manage Loans and other Services Account Management Financial Account (FINANCIAL ACCOUNT, FINANCIAL ACCOUNT TRANSACTION) Functional Area with minimal requirements to work with. Reviewing and analyzing the UDM for the Account Subject Area provided insights to just how complex this area can become. Functional Area has complex business rules with lots of process dependencies. The solution for this Functional Area could greatly benefit from a business rules engine and process workflow engine in addition to a good quality data model. Manage Loans and other Services Invoicing and Payment Management Invoice (INVOICE, ACCOUNT PAYMENT) Proposed model is flexible and supports all of s requirements. This model is the least complex and easiest to understand model of all. Requires the coordination of key process activities and business rules. Worth investigating if this Functional Area could benefit from a business rules engine and a workflow engine to coordinate the required activities. Manage Project, Analyze Risk / Project Management Work Effort Management Work Effort (RISK ANALYSIS, FINANCIAL PLAN, ACCOUNT NOTIFICATION) A flexible model that supports all of s requirements for their Project Management. Business rules in this functional area are relatively simple. The challenge for this Functional Area is the coordination of the activities. Believe that this Functional Area could benefit from a workflow engine. The Risk Analysis model provides a very comprehensive model, beyond the needs of but simple and flexible. The UDM are generalized and abstract data models, which is what the Chair needs to develop a family of software products to be used by many organizations with varying business requirements, hence the key criteria for the SSFA data model is that it provides flexibility. Flexible data models come with trade-offs, that is: 1. They do not communicate well or easily; especially to non-it professional therefore domain experts may not be able to validate the data model in its generalized state. 2. Some data models are so complex that some IT professionals will have difficulty understanding them, which may lead to incorrect implementation of the data models and eventual lead to corrupted data.

71 Financial Services logical data model for Social Economy based on UDM / The data models loose the rigorous specification of business rules at the data model level, i.e. relationship optionality, cardinality and more specific attributes and relationships. To expand on the last above point, once a logical data model is completed the next step is to evolve it into a physical data model. If the logical data model is more specific (i.e. less generalized) then the physical data model design activities could take advantage of DBMS features to implement business rules using features like stored procedures and database constraints. With a general data model these DBMS features need to be handled outside the DBMS through application code.

72 Financial Services logical data model for Social Economy based on UDM / Other Findings This section includes a couple of findings not related directly to the SSFA logical data model. During the analysis of the requirements, it was necessary to determine how to best document the functional requirements. Today, most software development projects chose Use Cases to document requirements. Given that the objective of this paper was not to produce a requirements document and only a few requirements were available it was decided to use a simple feature list with descriptions. The Chair will need to make a decision shortly, regarding the format to use to document the functional and non-functional requirements. The data model diagrams in this paper are produced using NetBeans 6.7 with the UML plug-in. The decision to use NetBeans and UML is due to fact that they are the tool and notation software developers are familiar with. Using UML to produce logical data model diagrams is not optimal. Ideally logical data model diagrams should communicate what the primary and foreign keys are for each entity, to do so with UML would have produced diagrams with lots of clutter. Given the number of entities wanting to appear in the LDM diagrams the decision was to omit the primary and foreign key information and include this information with the entity attribute descriptions. NetBeans 6.8 does not yet include a UML plug-in; the Chair needs to conduct a quick evaluation to determine the most appropriate tool for producing data model diagrams going forward.

73 Financial Services logical data model for Social Economy based on UDM / Recommendations During the process of analyzing the UDM and working through to understand some of the more complex data structures, it becomes apparent that the more complex the business rules are for a Functional Area the more complex the data model becomes. The complexity is often due to the data model wanting to satisfy the need for flexibility to accommodate current and future needs for new types of classifications, business rules, roles, statuses and entity relationships. One cannot help ask the question if there is a simpler more effective way to manage the business rules that does not involve having to produce complex data models that are difficult to communicate and maintain. It is for this reason that for those more complex Functional Areas the recommendation to further investigate if a solution that incorporates a business rules engine would better provide for flexibility and simplify the data structures is made. The same is true for those Functional Areas/activities that contain complex processes, the complexity of the data model increases as it tries to support the complex workflow needs. These Functional Areas/activities warrant an evaluation of the impact of including a workflow engines as part of the solution. Note: This suggestion to investigate incorporating a business rules engine and workflow engine for certain Functional Areas comes from someone next to no experience with business rules and workflow engines, and is thus making a big assumption that the implementation of the engines would simplify the data model. The Table 11-1: General Criteria for Evaluating a Data Model in Section 11.2 General Criteria for Evaluating a Data Model specifies Completeness as a criterion for good quality data model, that is, the ability for a logical data model to support the business requirements. The section also establishes that this is a criterion that the current SSFA logical data model does not meet, since the Chair does not have the complete requirements for SSFA. In fact a key premise of the Chair is to develop a flexible software application that will allow for supporting the needs of various Financial Services organizations, hence the need to develop a generic or generalized data model and a solution that incorporates a business rules engine and work flow engine. The concern is, in attempting to develop such a system the Chair will find itself in some form of analysis paralysis or continuous scope creep trying to satisfy the needs of the various Financial Services organizations that show an interest in the software and want to ensure their requirements make it into the product. To avoid this the Chair needs to organize itself to quickly establish what the core functions are for each Functional Area and focus on delivering the core functions with flexibility to allow for some variances in business rules and workflows for the social economy Financial Services organizations. As part of the overall solution the Chair also needs to provide a solution for how to include more complex extensions to the application, this may involve designing the application with hooks to extend functionality. Following are some suggestions that may help to quickly establish the core set of functions for SSFA: 1. Adopt an effective requirements management process that addresses the elicitation, gathering and documentation of requirements. 2. Identify who will have authority to make the key decisions regarding what functions should be included as part of the core system. 3. Identify requirements priority for functionality that most importantly or strongly supports the objectives of the Chair. For recommendation regarding what the next steps should be to further evolve the SSFA logical data model See Section 14 Future Work.

74 Financial Services logical data model for Social Economy based on UDM / Conclusion The UDM does live up to its objective of providing a jumpstart good quality logical data model that is extendable. With few resources and requirements the Chair has for SSFA: 1. An initial logical data model for each of the Financial Services Functional Areas that can be used: To elicit additional requirements To help build a prototype As base to further evolve the logical data model and eventual lead to the implementation of physical data models. 2. An understanding of common data modeling patterns that can be used for developing generic data models, mainly patterns for roles, statuses and categorizations. 3. An initial high level Functional Area model to build upon and structure the requirements (i.e. further breakdown the Functional Areas into functions, activities and features). 4. Identified Functional Areas that could benefit from integrating a business rules engine and/or a workflow engine. 5. A better understanding of the challenges regarding the development of a data model for SSFA to support the requirements of most Financial Services organizations in the social economy. The most difficult part of the developing a logical data model for SSFA is deciding if certain general/abstract UDM entities and their relationships should be included into the SSFA logical data model or if including them is overkill. Typically the business requirements call for only one or two different ways to classify an entity. If the number of ways to classify the entity is very stable and unchanging, then one needs not adopt the more generalized structures and can opt for the more specialized model. The more specific data models are advantageous in that they are more easily understood and show enforcement of business rules. The more generalizes /abstract data models have the advantage of flexibility and maintainability, hence much more adaptable to change, but they are more complex and do not communicate very well. There no right or wrong data model, but there are advantages and disadvantages to the various ways of modeling data and the main driver is the requirements.

75 Financial Services logical data model for Social Economy based on UDM / Future Work This section describes what the next steps should be to continue the development of SSFA and its logical data model. The existing logical data model needs to be validated against the requirements of at least one more Financial Services organization in the social economy which supports more services than, has a larger customer base and is based in France to identify some possible international concerns. The Contact Management Functional Area is currently the most complete and the Functional Area needed by all organizations, making it the ideal Functional Area to prototype to validate some of the Chair s design decision. The next Functional Areas to plunge into would be the ones that have been identified as possibly benefiting from solutions that integrate business rules and workflow engines. The Product Management Functional Area is the area that could benefit most from a business rules engine to define and manage the rules and Account Management Functional Area to apply the rules. The Work Effort Management Accounts Notification process is the area that could benefit the most from a workflow engine. As stated earlier a generic data models do not communicate well, business experts may have difficulty seeing their business through the proposed data structures. The Chair will most likely need to produce another layer of data models that allow for better communication with the business. As stated in Section 12 Recommendations the Chair needs to establish the SSFA core functions to be supported, produce the requirements specifications for these core functions and at the same time further evolve the logical data model to deliver core SSFA functionality Other Requirements Other Requirements The following features are currently integrated into the Lotus Notes application, the Chair needs to determine if incorporating into SSFA open source solutions for these features is within its current scope/mandate: 1. An electronic system, including support for mass mailing 2. Integration of a spread sheet software similar to Excel 3. Integration with a Document Management System 4. A Report Generator which includes support for producing dashboards Glossary of Terms Important to development projects is a Glossary of Terms for the domain, to ensure good communication between stakeholders including developers. For SSFA the Chair will also require a multilingual glossary of terms. Appendix Section 22 Appendix H French / English Terms contains a table

76 Financial Services logical data model for Social Economy based on UDM / 132 of initial financial services French terms found in the User Guides and their English translation, which need to be validated by a domain expert.

77 Financial Services logical data model for Social Economy based on UDM / 132 Bibliography Books [BB-1] [BB-2] [BB-3] [BB-4] Len Silverston The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises 2001, John Wiley & Sons, Inc. ISBN: Len Silverston The Data Model Resource Book, Vol. 2: A Library of Data Models for Specific Industries 2001, John Wiley & Sons, Inc. ISBN: Len Silverston and Paul Agnew The Data Model Resource Book, Vol. 3: Universal Patterns for Data Modeling 2009 Wiley Publishing, Inc. [BB-3] ISBN: Graeme C. Simsion and Graham C. Witt Data Modeling Essentials Third Edition 2005, Elsevier Inc. ISBN: Articles / Papers / Documents [BA-1] Guide d utilisation des outils de Gestion Informatises, 2007 [BA-2] Guide d utilisation de la base Gestion Financière, 2003 [BA-3] Interview with Len Silverston of Universal Data Models by Robert S. Seiner, Len Silverston Published: April 1, 2009 Copyright , The Data Administration Newsletter, LLC -- [BA-4] Universal Data Models: Simsion Interviews Silverston October 16, 2003 "Data Discussions" is a series of interviews with leading data management experts and practitioners, presented by Wilshire Conferences Wilshire Conferences, Inc. [BA-5] [BA-6] Developing High Quality Data Models By Matthew West September 2003, EPISTLE (the European Process Industries STEP Technical Liaison Executive) What Data Models Can t do By David C. Hay 1998, Essential Strategies, Inc

78 Financial Services logical data model for Social Economy based on UDM / 132 Sites Web [BW-1] Chaire de logiciel libre Finance sociale et solidaire [BW-2] [BW-3] [BW-4] l'association Internationale du Logiciel Libre (Ai2L) pour l'économie Sociale Effective Addressing for International Mail By Frank da Cruz The Kermit Project - Columbia University Conceptual, Logical, And Physical Data Models

79 Financial Services logical data model for Social Economy based on UDM / Appendix A - Contact Management 15.1 Directory Management Feature List and Business Rules Following are some key features, extracted from the Lotus Notes application user guides and meetings with analyst. Feature CM_FA_FT05: Maintain Society information in the Directory Description Capture information regarding a Society to be saved for later reference. Mandatory fields: name, preferred language, principle contact, main address, secondary address and headquarters telephone number. The different types of Societies are: Local Development Fund Enterprise Supplier Partner Government Agency Financial Institution CM_FA_FT10: Maintain Contact information in the Directory CM_FA_FT15: Make a Contact the principle contact CM_FA_FT20: List all Societies from the Directory CM_FA_FT25: List all Contacts for a Society CM_FA_FT30: Search and display Society information Capture Contact information for future reference. Mandatory: first Name, last Name, postal address, phone number, preferred language, address. Assign a principle contact to a Society. Notes: must delete the association to the previous principle contact and assign the role to the newly selected contact. Provide a list of all the Societies contained in the Directory. Provide a list of all Contacts for a specific Society. Display the list in alphabetic order showing the contact name, address, address, and society. Display all Societies that match a search criterion. Allow for searching by: Name, Contact, Region, Activity Sector (others to be defined). Display the results in alphabetic order for each Society: Name, main address, headquarters telephone number and principle contact. Allow for the selection of a specific Society and display the following details: Administrative Region City Judicial status Year founded Organization profile Union present (Boolean)

80 Financial Services logical data model for Social Economy based on UDM / 132 Telephone, fax, Enterprise activity Region Activity sector Number of employees Job statistics (last 5 years). CM_FA_FT35: Search and Display Contact information Display all Contacts in the Directory that match a search criterion. Display the results in alphabetic order for each Contact: contact name, society address, address and Society. Display all Contacts for a Society and display in alphabetic order the following information for each: contact name, address and address. CM_FA_FT40: Propagate Society address change to its Contacts CM_FA_FT45: Maintain Job Statistics for a Society CM_FA_FT50: View the Job Statistics for a Society CM_FA_FT55: Maintain information regarding Face to Face meetings CM_FA_FT60: Maintain information regarding telephone calls Following an update to the main or secondary address of a Society, propagate that address to all contacts that have the old address. The system must prompt the user before updating the Contact s address to the new Society address. Maintain for Enterprises and Local Development Funds up to 5 years of job statistic data. The data is to be maintained by yea, includes: annual sales, number of jobs created, number of jobs retained and equivalent full time employees. Display the Job Statistics for an Enterprise or Local Development Fund Maintain a log of all meetings held with a Contact regarding a Project. Allow for the ability to associate appropriate documents to the meeting. Maintain a log of all telephone conversations held with a Contact regarding a Project. Allow for the ability to associate appropriate documents to the phone calls. Following are some key business rules, extracted from the Lotus Notes application user guides and meetings with analyst. In the Notes column below, are observations regarding the how the rules would fit into the SSFA generic model. Business Rules Description Notes Valid preferred languages are either French or English. CM_FA_BR0010: Preferred Language Each Financial Services organization will have different values for preferred languages. CM_FA_BR0015: Society must have a Contact CM_FA_BR0020: Principle Contact: A Society must have at least one Contact A Society must have a principle contact. A Society can have only one principle contact. Suggest this be made a business rule for all Financial Services organizations. Suggest this be made a business rule for all Financial

81 Financial Services logical data model for Social Economy based on UDM / 132 Services organizations. CM_FA_BR0025: Authorized to update Directory information CM_FA_BR0035: Deleting a Society CM_FA_BR0040: Valid Society types CM_FA_BR0045: Valid Client Society subtype CM_FA_BR0050: Contacts must belong to a Society. CM_FA_BR0055: Contact may belong to more than one society Any user who has access to the system can update Society and Contact information. For a Society to be deleted no Contacts nor Projects must be associated to it. Valid Society Types are: Client, Vendor, Partner, and other Resources. Valid types for Client Society types are: Private Enterprise, Collective / Coop Enterprise and Other. A Contact must belong to a Society. Believe this the result of a defect in the current Lotus Notes application. Need a solution to be able to control which user has update access to which entities/attributes For we would turn this feature off for Society and Contact since all employees have update authority for Directory information. Suggest we make this a business rule for all Financial Services organizations. Should be handled via reference tables whose values would be specific per Financial Services organization. Need to determine the required classification and level classification for the ORGANIZATION entity. This rule will most likely not apply to all Financial Services organizations. Believe other Financial Services organization will want to data model to support the fact that a Contact may belong to more than one Organization People and Organization Entities and Attributes Note: the entity descriptions are based on description provided in The Data Model Resource Book volume 1 19, volume 2 20 and volume Attributes definitions are general definitions that need to be validated by a domain expert. 19 The Data Model Resource Book, Volume 1, A Library of Universal Data Models for all Enterprises, by Len Silverston, 2001, John Wiley & Sons, Inc. [BB-1] 20 The Data Model Resource Book, Volume 2, A Library of Universal Data Models by Industry Types, by Len Silverston, 2001, John Wiley & Sons, Inc. [BB-2] 21 The Data Model Resource Book, Volume 3, Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, 2009, Wiley Publishing, Inc. [BB-3]

82 Financial Services logical data model for Social Economy based on UDM / 132 Further notes regarding the tables listing the entity attributes: The values for the column Constraints are: o PK = Primary key o FK = Foreign key o M = Mandatory attribute o O = Optional attribute The column Added for indicates those attributes added to the entity to meet requirements. Entities have a primary key that is a non-meaningful unique sequence numbers, known as a surrogate key, which is also used to related entities to each other. Having keys without any inherent meaning is a common data modeling practice to avoid the ripple effect of data inconsistencies and other problems should value or pattern of the key change. Also identified are alternate identifiers to the entity that uniquely identify the entity, usually this is a combination of Foreign keys shown as PK,FK in the Constraints column Party Stores the common information that will not change over time about an organization or a person of interest. PARTY is the supertype of PERSON and ORGANIZATION. Party ID PK Uniquely identifies a PARTY. Party Type ID FK Identifies the Party Type. Preferred Language O The preferred language that this Party wishes to be communicated in. Preferred O Identifies the Party s preferred mode of communication. Communication Event Type Person Stores information on a particular person independent of their job or roles. Party ID PK Uniquely identifies a PERSON. First Name M First name of the person. Last Name M Last name of the person. Middle Name O Middle name of the person. Salutation O Salutation to be used when referring to the person. Gender O Person s gender. Date of Birth O Person s date of birth. Social Insurance Number O Person s social insurance number.

83 Financial Services logical data model for Social Economy based on UDM / 132 Note: the Entity PERSON in the UDM lists many more attributes like height and weight, marital status and current passport number, the above list of attributes contains only those attributed deem required for a Financial Services application Organization A legal or informal entity, that stores information about a group of people with common propose, for example: corporation, department, division, government agency or non-profit organization. Party ID PK Uniquely identifies an ORGANIZATION. Name M Legal name of the Organization. Acronym O Acronym of the Organization. Preferred Language M The preferred language that this organization wished to be communicated in. Year Founded M The year the organization was founded. Federal Tax Id Number O Organization Federal Tax Id number. Provincial Tax Id Number O Organization Provincial Tax Id number. Web Address O Organization s web address. Referred to by O Free text, provides the first and last name of the person who referred this organization to the financial services organization. Note: maintains the French and the English names of a Society in its Directory; it is assume for the SSFA data model all Internationalization language requirements will be handled separately through the solution architecture and design Party Type Stores the set of allowed types for the PARTY entity. Contains the complete set of allowable types some which may not appear in the LDM diagram. Since organizations and people may be classified in many ways there is a many to many relationship between PARTY and PARTY TYPE. The many to many relationship means that this relationship requires further analysis. refers to this type of data as Profile. This entity could also be used to distinguish a PARTY of type PERSON vs. a PARTY of type ORGANIZATION. Note: The information provided by this entity may be used for mass mailing, e.g. Financial Services organization wants to mail flyers only to organizations of type Women owned business. Party Type ID PK Unique identifier for the PARTY TYPE. Name M The value of the allowed type. example: the set values of PARTY TYPE could possibly include, Women s shelter, Women owned business, Local Development Fund, Enterprise, Government Agency,

84 Financial Services logical data model for Social Economy based on UDM / 132 Financial Institution, Private enterprise, Coop enterprise Financial Institution An organization involved in providing financial services, for example: banks, lending organizations, credit unions, brokerage services, and insurance companies. A subtype of ORGANIZATION Government Agency An organization that establishes guidelines enforces them and communicates requirements to financial services organizations. A subtype of the ORGANIZATION entity Local Development Fund An organization that receives loans from a Financial Services organization, and in turn uses those funds to help in the development of organizations in their jurisdiction. A subtype of the ORGANIZATION entity. The attributes listed below are specific to ; further analysis is required to determine if they should be included in the supertype ORGANIZATION. Party ID PK,FK Unique identifier of the Local Development Fund. Union Present O Boolean, indicates whether the organization has a union. Level of development M Identifies what stage of development the organization is in. Possible values are: Start-up, Development, Expansion, Consolidation, Reorganization, Merger, Acquisition Enterprise A social economy organization that borrows money from a Financial Services organization. A subtype of the ORGANIZATION entity. It is believed that further analysis will show the ENTERPRISE entity is needed to store additional attributes to those defined for ORGANIZATION and different attributes than a LOCAL DEVELOPMENT FUND

85 Financial Services logical data model for Social Economy based on UDM / Job Statistics Stores information regarding job statistics of an ORGANIZATION. For the entity store job statistics information for an ENTERPRISE or a LOCAL DEVELOPMENT FUND. Entity added to the data model to address requirement. Job Statistics ID PK Uniquely identifies a JOB STATISTICS. Party ID PK,FK Unique identifier of the organization for which the job statistics belongs to. Year PK The year of the job statistics. Annual Sales O Organization s annual sales for that year. Number of Jobs Created O The number of new jobs the organization created in the year. Number of Jobs Retained O The number of jobs the organization was able to retain in the year. Number of Equivalent O The number of equivalent full time employees maintained in the Full Time year Party Role This entity maintains information associated with each role that a PERSON or an ORGANIZATION plays. Information related to a PERSON or ORGANIZATION that applies only to a specific role. PARTY ROLE is the supertype for SUPPLIER, CUSTOMER, CONTACT, PARTNER and INTERNAL ORGANIZATION. Party Role ID PK Uniquely identifies the PARTY ROLE. Party ID PK,FK Identifies the Party. Party Role Type ID PK,FK Identifies the role the Party plays. From Date O The start date for the period the Party Role is valid. Thru Date O The end date of the period the Party Role is valid Party Role Type Maintains the classification of PARTY ROLE. Stores the complete set of values allowed for the PARTY ROLE entity. Note this is not the same data as for a specific role. Instances of Part Role Type correspond to a subtype of PARTY ROLE.

86 Financial Services logical data model for Social Economy based on UDM / 132 Party Role Type ID PK Uniquely identifies the PARTY ROLE TYPE. Name M The value of the Party Role Type. Possible values are: Contact, Employee, Internal Organization, Customer, Supplier, Partner. Comments O Free text, further explains the Party Role Contact Stores role type information regarding a person who acts as representative of an ORGANIZATION. CONTACT is a subtype of PARTY ROLE. Party ID PK,FK Uniquely identifies the PARTY. Party Role Type ID PK,FK Identifies the PARTY ROLE TYPE. Value = Contact. From Date O The effective date of when the Party became a Contact. Thru Date O The end date of the Party s relationship as a Contact. Title O Titles of the Contact, possible values are: Promoter, Director, President. Service O Free text. Provides information regarding the department or unit the Contact belongs to in his/her organization Principle Contact Stores role type information about the person who acts as the main/principle representative for an ORGANIZATION. PRINCIPLE CONTACT is a subtype of PARTY ROLE. Party ID PK,FK Uniquely identifies the PARTY. Party Role Type ID PK,FK Identifies the Party Role Type of Principle Contact. From Date O The effective date of when the Party became a Principle Contact. Thru Date O The end date of the Party s relationship as a Principle Contact. Title O Titles of the Contact, possible values are: Promoter, Director, President. Service O Free text. Provides information regarding the department or unit the Principle Contact belongs to in his/her organization.

87 Financial Services logical data model for Social Economy based on UDM / Employee Maintain information regarding a PERSON hired by the Financial Services organization under a contract of employment to perform work on a regular basis at the organization s request. EMPLOYEE is a subtype of PARTY ROLE. Constraints Description Added for Attribute Party ID PK,FK Uniquely identifies the PARTY. Party Role Type ID PK,FK Identifies the Party Role. Type = Employee. From Date O The effective date of when the Party became an EMPLOYEE. Thru Date O The end date of the Party s relationship as an employee. Employee Number M A unique number assigned to each employee. User ID O A unique identifier assigned to the employee, used to access the organization s computer network. Company ID M The employee s unique identifier Internal Organization INTERNAL ORGANIZATION is a subtype of PARTY ROLE Customer CUSTOMER is a subtype of PARTY ROLE Supplier A party that provides services or goods to the Financial Service organization. SUPPLIER is a subtype of PARTY ROLE Partner A party that collaborates with the financial services organization to provide financial services to a Customer, and essentially agrees to share in the profits or losses. PARTNER is a subtype of PARTY ROLE Party Relationship Stores information related to the associations (relationships) that PERSONs and ORGANIZATIONs have with each other within the context of the role that they play. Allows for parties to be related to other parties and maintains the respective roles in the relationship.

88 Financial Services logical data model for Social Economy based on UDM / 132 There are 3 types of relationships those that: 1. people have within organizations 2. people have with other people 3. organizations have with other organizations. PARTY RELATIONSHIP is a supertype that maintains the attributes From Date and Thru Date to capture the valid time frames of the relationship, indicating when party formed a relationship and when (if) it ended. PARTY RELATIONSHIP is a supertype of: ORGANIZATION CONTACT RELATIONSHIP CUSTOMER CONTACT RELATIONSHIP PARTNERSHIP EMPLOYMENT ORG PRINCIPAL CONTACT RELATIONSHIP. Party ID From PK,FK Identifies the (from) Party in the relationship. Party ID To PK,FK Identifies the (to) Party in the relationship. From Date M Provides the date the relationship became valid. Thru Date O The end date of the relationship. This attribute is needed show valid time frame for the relationship. Party Role ID To PK,FK Identifies the role of the from Party in the relationship. Party Role ID From PK,FK Identifies the role of the to Party in the relationship. Party Relationship Type FK Identifies the type of Party Relationship. ID Status Type ID FK The current status of the relationship: Possible values are: Active, Not active. Comment O Free text that further explains the Party Relationship Party Relationship Type Maintains the classification of PARTY RELATIONSHIP. Stores the complete set of values allowed for the PARTY RELATIONSHIP. Party Relationship Type PK Uniquely identifies the PARTY RELATIONSHIP TYPE. ID Name M The value of the relationship. Possible values are: Customer Contact Relationship, Employment, and Principle Contact Relationship. Description O Free text. Describes the nature of the relationship in more details or the meaning behind the relationship.

89 Financial Services logical data model for Social Economy based on UDM / Contact Mechanism Entities and Attributes Contact Mechanism Maintains an actual contact mechanism, which is a way a person or organization can be contacted. CONTACT MECHANISM subtypes are: TELECOM NUMBER (access via telecommunication lines e.g. phones, faxes, pager, cellular/mobile) ELECTRONIC ADDRESS POSTAL ADDRESS. Contact Mechanism ID PK Uniquely identifies a CONTACT MECHANISM. Contact Mechanism Type ID FK Identifies the type of Contact Mechanism Telecom Number A subtype of CONTACT MECHANISM. Contact Mechanism ID PK,FK Uniquely identifies the CONTACT MECHANISM. Area Code M Identifies the local calling area for of a telecom number. Contact Mechanism M The actual telecom number (subscriber number). Country Code O The country code of the telecom number Electronic Address A subtype of CONTACT MECHANISM. Contact Mechanism ID PK,FK Uniquely identifies the CONTACT MECHANISM. Electronic Address String M The actual address or a web site address Postal Address Maintains a collection of information to which mail is delivered to. A subtype of CONTACT MECHANISM.

90 Financial Services logical data model for Social Economy based on UDM / 132 Contact Mechanism ID PK,FK Uniquely identifies the CONTACT MECHANISM. Street Address Line 1 M First line of the address. Street Address Line 2 O Second line of the address. Street Address Line 3 O Third line of the address. Directions O Free text, provides directions to this address Contact Mechanism Type Stores the complete set of values allowed for the CONTACT MECHANISM entity. Contact Mechanism PK Uniquely identifies the CONTACT MECHANISM TYPE. Type ID Name M The value of the contact mechanism type. Possible values are: Telecom Number, Postal Address, and Electronic Address Party Contact Mechanism Maintains which CONTACT MECHANISMs are related to which PARTY. Party ID PK,FK Identifies the Party. Contact Mechanism ID PK,FK Identifies the Contact Mechanism. From Date M The start date for the valid period for the Party s Contact Mechanism. Thru Date O The end data of the valid period for the Party s Contact Mechanism. Non Solicitation ID O Boolean, Indicates whether the Contact Mechanism is to be used for contacting the Party for solicitation purposes. Comment O Free text, further details regarding the Party s Contact Mechanism Party Contact Mechanism Purpose Stores the purpose or intended use of the contact mechanism for each Party. Party ID PK,FK Identifies the Party

91 Financial Services logical data model for Social Economy based on UDM / 132 Party Contact Mechanism ID Contact Mechanism Purpose Type PK,FK PK,FK Identifies the Party s Contact Mechanism. Identifies the Purpose Type of the Contact Mechanism for the Party. From Date M The start date for the valid period to use the Contact Mechanism for the identified purpose. Because the purposes of contact mechanisms change over time the From Date and Thru Date attributes identify when the purpose is valid. Thru Date O The end date of the valid period to use the Contact Mechanism for the identified purpose Contact Mechanism Purpose Type Stores the complete set of values allowed for the CONTACT MECHANISM PURPOSE. Contact Mechanism Purpose Type PK Uniquely identifies the CONTACT MECHANISM PURPOSE TYPE. Name M The value of the Contact Mechanism Purpose Type. Possible Values are : General Phone Number, Main Fax Number, Personal Phone Number, Web Site, Work Address, Cell Number, Personal Address Geographic Boundary Maintains any type of encompassing area or the jurisdiction that an organization may use to manage their business. GEOGRAPHIC BOUNDARY possible subtypes are: COUNTRY REGION CITY PROVINCE STATE TERRITORY. Geographic Boundary PK,FK Uniquely identifies the GEOGRAPHIC BOUNDARY. ID Geographic Boundary Type id FK Identifies the Geographic Boundary Type for the Geographic Boundary. Name M The name of the Geographic Boundary. Abbreviation O The abbreviation for the Geographic Boundary. Geographic Boundary Code O The code for the Geographic Boundary. Example the Canada country code = 1 for long distance calling.

92 Financial Services logical data model for Social Economy based on UDM / 132 Following are example of REGIONs (which is a subtype of GEOGRAPHIC BOUNDARY): Bas Saint Laurent 02 Saguenay Lac St. Jean 03 Quebec 06 Montreal 08 Abitibi-Temiscamingue Contact Mechanism Boundary Maintains the geographic boundaries of a contact mechanism. Example: a CONTACT MECHANISM of type POSTAL ADDRESS may reference one or more CONTACT MECHANISM BOUNDARY, which are each for a GEOGRAPHIC BOUNDARY. Contact Mechanism PK Uniquely identifies the CONTACT MECHANISM BOUNDARY. Boundary ID Contact Mechanism ID FK Identifies the Contact Mechanism. E.g. the actual postal address. Geographic Boundary ID FK Identifies the Geographic Boundary. E.g. the Province the postal address belongs in. From Date M The start date for the valid period for the Contact Mechanism Boundary. Thru Date O The end date of the valid period for the Contact Mechanism Boundary Geographic Boundary Type Stores the complete set of values allowed for the GEOGRAPHIC BOUNDARY entity. Geographic Boundary PK Uniquely identifies the GEOGRAPHIC BOUNDARY TYPE. Type ID Name M The value of the Geographic Boundary Type. Possible values are: Region, Country, City, Province, Postal Code, MRC Geographic Boundary Association Maintains the relationship between GEOGRAPHIC BOUNDARY subtypes. For example this entity allows for relating a city to a province. Geographic Boundary PK Uniquely identifies the GEOGRAPHIC BOUNDARY ASSOCIATION. Association ID Geographic Boundary ID From FK Identifies the from Geographic Boundary in the association relationship.

93 Financial Services logical data model for Social Economy based on UDM / 132 Geographic Boundary ID To FK Identifies the to Geographic Boundary the association relationship. Geographic Boundary FK Identifies the Geographic Boundary Association Type. Association Type ID From Date M The start date for the valid period for the Geographic Boundary Association. Thru Date O The end date of the valid period for the Geographic Boundary Association Geographic Boundary Association Type Stores the complete set of values allowed for the GEOGRAPHIC BOUNDARY ASSOCIATION entity. Geographic Boundary Association Type ID PK Uniquely identifies the GEOGRAPHIC BOUNDARY ASSOCIATION TYPE. Name M The value of the geographic boundary association type. Possible values are: Region Province Relationship, City Province Relationship, and Province Country Relationship. Parent Geographic Boundary Association Type ID FK (OPTIONAL) To be further investigated Communication Event Feature List Following are some key features, extracted from the Lotus Notes application user guides and meetings with analyst. Feature CM_FA_BR10: Log Telephone Calls CM_FA_BR15: Log Face to Face or Meetings CM_FA_BR20: Link documents to a Telephone call or meeting Description Allow for the logging of information regarding a placed or received telephone call related to a Project. Information to capture: Person who placed and who received the call, call participates, call date and time, and notes regarding the call. Allow for the logging of information regarding a face to face meeting or conference related to a Project. Information to capture: Meeting date, meeting time, participants and meeting location. Allow for associating any type of document to a telephone call or meeting. Document type may be in the following formats: Word, Excel, PDF, gif, jpeg.

94 Financial Services logical data model for Social Economy based on UDM / Communication Event Entities and Attributes Communication Event Maintains the history of communication exchanges held between Party s within the context of their PARTY RELATIONSHIP. COMMUNICATION EVENT is the supertype of: FA COMMUNICATION WEB SITE COMMUNICATION LETTER CORRESPONDENCE PHONE COMMUNICATION FACE TO FACE COMMUNICATION. Communication Event PK Uniquely identifies the COMMUNICATION EVENT. ID Project ID FK Identifies the PROJECT for which the communication event belongs to. Status ID FK Identifies current status of the communication event Case ID FK Identifies the case to which the communication event belongs to. Contact Mechanism Type ID FK Identifies the type of contact mechanism used for the communication event. Party ID From FK Identifies the party that originated the communication event. Party ID To FK Identifies the party that was the recipient of the communication event. Role Type ID From FK The identifier that specifies the role type of the party that originated the communication event. Role Type ID To FK The identifier that specifies the role type of the party that the received the communication event. Date Time Started M The date and time the communication event was initiated. Note O Free text, further details the communication event. Date Time Ended O The date and time the communication event terminated Face to Face Communication Maintains information regarding face to face meetings held between Parties within the context of their role. Note: this entity is a subtype of COMMUNICATION EVENT. The attributes included here are in addition to those specified for COMMUNICATION EVENT. Meeting Location FK The identifier of the meeting location. Contact Mechanism ID Other Participants O Free text, provides details regarding who else participated in the meeting.

95 Financial Services logical data model for Social Economy based on UDM / Phone Communication Maintains information regarding phone conversations held between Parties within the context of their role. Note: this entity is a subtype of COMMUNICATION EVENT. The attributes included here are in addition to those specified for COMMUNICATION EVENT. Other Participants O Free text, provides details regarding who else participated in the phone conversation (as in the case of a conference call) Communication Event Purpose Store information regarding the purpose of a COMMUNICATION EVENT. Communication Event PK,FK Identifies the purpose of the communication event. Purpose ID Type Communication Event PK Identifies the Communication Event. ID Description M Free text, further details of the nature of the communication event Communication Event Purpose Type Maintains the complete set of valid values allowed for the COMMUNICATION EVENT PURPOSE. Communication Event PK Unique identifier for COMMUNICATION EVENT PURPOSE. Purpose ID Type Name M The value of the communication event purpose. Possible values are: Annual Review, Follow-up, Training, Information Communication Event Status Maintains the history a Communication Event has gone through including the most up to date status. Communication Event PK Identifies the COMMUNICATION EVENT. ID Communication Event Status Type ID PK,FK Identifies the communication event status.

96 Financial Services logical data model for Social Economy based on UDM / 132 Status Date Time M Date the status was last updated Communication Event Status Type Maintains the complete set of valid values allowed for the COMMUNICATION EVENT STATUS. Communication Event PK Uniquely identifies the COMMUNICATION EVENT STATUS TYPE. Status Type ID Name M The value of the Communication Event Status Type. Possible values are: Scheduled, Completed, Cancelled, Pending, and in progress Case Maintains a link to a series or group of related Communication Events for a particular issue. Case ID PK Uniquely identifies the CASE. Status Type ID FK Identifier for the status of the communication event. Description M Free text, provides further details regarding the case. Start Date Time O The date and time when the case was opened Case Role Maintains for a particular CASE the role a Party plays. Case ID PK,FK Identifies the case. Party ID PK,FK Identifies a party involved in the case. Role Type ID PK,FK Identifies the role of the party involved in the case. E.g. Responsible, Assisting Case Status Type Maintains the complete set of valid values allowed for the CASE STATUS TYPEs. Case Status Type ID PK Uniquely identifies the CASE STATUS TYPE. Name M The value of the case status. Possible values: open, closed, in progress

97 Financial Services logical data model for Social Economy based on UDM / Appendix B Product Management 16.1 Product Management Feature List Following are some key features, extracted from the Lotus Notes application user guides and meetings with analyst. Note: The details provided here in terms of the rates for the feature descriptions are examples only. Feature Description PM_FA_FT05: Regular Loan System provides the ability to create Regular Loan products that exhibits the following features: The base Interest rate is based on the prime interest rate The fixed interest rate may vary between 1% and 4% Grace period may apply on the principle for the first 1 to 4 months The repayments are due monthly. PM_FA_FT08: Revolving Loan PM_FA_FT10: Guarantee Fee PM_FA_FT15: Performance Fee PM_FA_FT20: Follow-up- Fee PM_FA_FT25: Grace Period on Principle PM_FA_FT10: Grace Period on Interest System provides the ability to create Revolving Loan products that exhibits the following features: The base Interest rate is based on the prime interest rate The fixed interest rate may vary between 2% and 5% Grace Period does not apply The repayments are due anytime before the end of the Contract. System provides the ability to create Guarantee Fee products that exhibits the following features: The fee rate can be between.5% to 2% of the Loan (the customer has taken with another Financial Institution) The fee is charged on a monthly basis for the duration of the Loan Grace Period does not apply. System provides the ability to create Performance Fee products that exhibits the following features: The fee rate can be in the range of 3% to 6% of the borrower s profits. The fee is charged annually on the end date of the Borrower s fiscal year. System provides the ability to create Follow-up Fee products that exhibits the following features: The fee rate can be between.5% to 2% of the Loan The fee is charged on a monthly basis for the duration of the Loan. System allows for Grace Periods on the Principle amount. The number of periods can be between 1 to 6 months. System allows for Grace Periods on the Interest amount. The number of periods can be between 1 to 6 months.

98 Financial Services logical data model for Social Economy based on UDM / Product Management Entities and Attributes Financial Product Maintains the financial services product or service offered to customers by the Financial Services organization. Product ID PK Uniquely identifies the PRODUCT. Name M The name of the product Product Category Maintains the possible values of classification for FINANCIAL PRODUCTs that may be offered by a Financial Services organization. This entity directly classifies products, examples of PRODUCT CATEGORY are: INVESTMENT VEHICLE (MUTUAL FUND, SECURITY INVESTMENT), LOAN PRODUCT, Deposit product. The product categories would be mostly used for reporting on profitability, sales and customer services. PRODUCT CATEGORY subtypes are: LOAN PRODUCT, which has as subtype: o LOAN o REVOLVING CREDIT INVESTMENT VEHICLE which has a subtype: o SECURITY which has a subtype MONEY MARKET SAVINGS PRODUCT. Product Category ID PK Uniquely identifies the PRODUCT CATEGORY. Name M The value of the product category. Possible values are: Loan Product, Investment Vehicle, Savings Product Product Category Classification Maintains the different categories for the FINANCIAL PRODUCTs. Note: The key difference between categorization and a type is that a categorization is more comprehensive than a type, and it involves different ways to classify an entity, that is, a categorization includes many different types of types page 189 The Data Model Resource Book, Volume 3, Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, 2009, Wiley Publishing, Inc. [BB-3]

99 Financial Services logical data model for Social Economy based on UDM / 132 Product Category ID PK Uniquely identifies the PRODUCT CATEGORY CLASSIFICATION. Product ID PK, FK Identifies the Financial Product. From Date PK The date the Product was placed under the Category Classification. Thru Date O The date the Product was removed from the Category Classification. Comment O Free text, further details regarding the classification of the product under the specified category Product Feature This entity stores the governing characteristics that make up a FINANCIAL PRODUCT. Typically PRODUCT FEATUREs have many FUNCTIONAL SETTINGS. Examples of features are: Statement, interest rate, annual fee and grace period. Each feature may have FUNCTIONAL SETTINGS that provide the parameters that apply to the feature. Subtypes are: INTEREST RATE FEATURE STATEMENT FEATURE MEDIA FEATURE FEE FEATURE. Product Feature ID PK The unique identifier for the PRODUCT FEATURE. Description M The description of the Product Feature. Possible values are: Interest rate feature, Statement feature, Media feature, and Fee feature Product Feature Applicability Maintains the set of available PRODUCT FEATURES or governing characteristics that make up or apply to a specific FINANCIAL PRODUCT. Product ID PK,FK Identifies the PRODUCT. Product Feature ID PK,FK Identifies the PRODUCT FEATURE. From Date PK The date the Product Feature was assigned to the Financial Product. Thru Date M The end date for which the feature is included as part of the Financial Product. The From Date and Thru Date provide the valid time frame for which the Product Feature is applicable to the Financial Product. Value O The actual value of the Product Feature that is applicable to the Financial Product. Possible values are: Interest rate, Statement, Annual fee.

100 Financial Services logical data model for Social Economy based on UDM / Functional Setting Stores the operational aspect that control how a PRODUCT FEATURE and FINANCIAL PRODUCT operate. FUNCTIONAL SETTING may apply at the FINANCIAL PRODUCT level or the PRODUCT FEATURE level. FUNCTIONAL SETTINGS provide the parameters that apply to the FINANCIAL PRODUCT or PRODUCT FEATURE. Example: A FINANCIAL PRODUCT of REGULAR LOAN, with a PRODUCT FEATURE of Statement may have a FUNCTIONAL SETTING value of Prepare statement every 60 days. Functional Setting ID PK The unique identifier for the FUNCTIONAL SETTING. Description M The description of the functional setting. Possible values are: Applied at month-end, Sent every 90 days, Charge at renewal period Functional Setting Applicability Maintains the FUNCTIONAL SETTINGS that apply to a FINANCIAL PRODUCT or the PRODUCT FEATURE. Outlines the parameters for when the Product Features are applied. Functional Setting PK The unique identifier for the FUNCTIONAL SETTING APPLICABILITY. Applicability ID Functional Setting ID PK,FK Identifies the Functional Setting. Product Feature ID FK Identifies the Product Feature. Product ID FK Identifier for the product. From Date M The start date from which the functional setting is valid for a feature for the product. Thru Date M The end data of the valid period for the functional setting applies for the feature of to the Product. Value O The actual value associated with of the application of the Functional Setting. Possible values are: Apply at month end, Apply on the 1rst working day of the month, Monthly, Annually Financial Product Regulations and Rules Management Entities and Attributes Financial Regulation Maintains the regulation text as provided by a financial governing agency. Subtypes are:

101 Financial Services logical data model for Social Economy based on UDM / 132 GOVERNMENT REGULATION ORGANIZATION REGULATION. Financial Regulation ID PK Uniquely identifies the FINANCIAL REGULATION. Description M The short description of the Financial Regulation. Text O The actual text of the Financial Regulation Regulation Requirement Maintains the Financial Services organization s understanding of a FINANCIAL REGULATION and what is required by the organization to abide by the regulation. Regulation PK Uniquely identifies the REGULATION REQUIREMENT. Requirement ID Agreement Term ID FK Identifies the Agreement Term negotiated with Customers that impose the Regulation Requirement (This attribute is mutually exclusive with the attribute Financial Regulation ID). Financial Regulation ID FK Identifies the Financial Regulation for which the Regulation Requirement is based on. (This attribute is mutually exclusive with the attribute Agreement Term ID) Description M Free text, provides the Regulation Requirement details Financial Product Rule Maintains the entities that are impacted by REGULATION REQUIREMENT, which may be any number of FINANCIAL PRODUCT, PRODUCT CATEGORY, PRODUCT FEATURE or FUNCTIONAL SETTING. Financial Product Rule PK Uniquely identifies the FINANCIAL PRODUCT RULE ID Agreement Term ID FK Identifies the Agreement Term negotiated with customers that imposed the Financial Product Rule. Functional Setting ID FK Identifies the Functional Setting impacted by the Financial Product Rule Product Category ID FK Identifies the Product Category impacted by the Financial Product Rule Product Feature ID FK Identifies the Product Feature impacted by the Financial Product Rule Product ID FK Identifies the Financial Product impacted by the Financial Product Rule Regulation Requirement ID FK Identifies the Regulation Requirement that imposed the Financial Product Rule. Description M Free text, provides the Financial Product Rule details. From Date M The start date for the valid period of the Financial Product Rule.

102 Financial Services logical data model for Social Economy based on UDM / 132 Thru Date O The end date of the valid period for the Financial Product Rule. Rule Value O Provides the Financial Product Rule value.

103 Financial Services logical data model for Social Economy based on UDM / Appendix C Financial Agreement Management 17.1 Contract Management Feature List and Business Rules Following are some key features, extracted from the Lotus Notes application user guides and meetings with analyst. Feature FA_FA_FT10: Create a Loan Contract FA_FA_FT15: Generate Payment schedule Description Provide a feature to allow for the entering of loan contract information used to gather information needed for issuing a loan agreement and repayment schedule. Include the following information as part of the contract: Lenders Terms of the loan Payment schedule Fees Grace Periods. For loans contract produce the payment schedule in Excel file format, with the following fields: payment date, interest, capital, payment for the month, balance. The system must also generate a reimbursements schedule as part of the contract which includes the following fields: capital, balance, period, maturity date, interest amount and payment amount. FA_FA_FT20: Display Contract and all its terms FA_FA_FT25: Print the Contract FA_FA_FT30: Display a Loan Contract summary FA_FA_FT30: Contract preconditions Allow for the viewing of the Contract including all the conditions and terms. Format and allow for printing of the Contract. Provide a Contract summary which includes for a loan contract the following basic information: the Contract number, amount, base interest rate, fixed interest rate, effective date, duration and status. Allowing for the capturing of a contract s pre-conditions that need to be met before the contract may be approved. Following are some key business rules, extracted from the Lotus Notes application user guides and meetings with analyst. The Notes column, are observations regarding the how the rules would fit into the generic model. Business Rules Description Notes FA_FA_BR0010: Send completed contract to Once all contract information is captured the complete contract is sent to a employee for verification.

104 Financial Services logical data model for Social Economy based on UDM / 132 FA_FA_BR0015: Contract to Project Relationship FA_FA_BR0020 Contract Change Notification FA_FA_BR0025: Limit number of Partners for a Contract. FA_FA_BR0030: Borrower details for a Contract FA_FA_BR0035: Partner details for a Contract FA_FA_BR0040: Loan Terms required fields FA_FA_BR0045: Contract pre-conditions FA_FA_BR0050: Close Reimbursed Contract FA_FA_BR0055: Reimbursement before maturity A Contract must be linked to one and only one Project. Any changes made to a Contract must be followed by a notification to a employee for verification. A contract may not have more than 5 Partners associated with it. Believe this is a limitation set by the Lotus Notes application and not specifically a business rule. Following information must be provided for each borrower: enterprise name, acronym, region, address, salutations, first and last name of signature. Following information shall be provided for each Partner in a Contract: organization name, organization address, principle contact, function, city, region, phone, fax and address. Following are required fields for a loan: amount (digits and letters), number of loan payments, number of months, capitalization type( monthly, quarterly, annually, semiannually), effective date, monthly payment type, base interest rate and fixed interest rate A contract may only be approved if all the pre-conditions have been met. To close a reimbursed contract all payments must have been applied/made. Close the Project once the loan is reimbursed in total. A loan may be totally reimbursement before maturity date. Additional business rules are required. Most other Financial Services organizations may need to link to an Account. This could be a generic requirement. An internal task can be triggered for someone to review the contract. Depending on the Financial Services organization the mandatory fields and default values will vary. Depending on the Financial Services organization, the mandatory fields and default values will vary. A solution is needed to establish which data attributes are mandatory fields for Financial Services organization. Depending on the Financial Services organization the mandatory fields and default values will vary. This could be a generic business rule. For the generic solution believe this business rule is related to the Loan Account and not the Agreement. Also an end to an agreement implies a close of the Account. Generic business rule for the loan lifecycle. For the generic solution believe this business rule is related to

105 Financial Services logical data model for Social Economy based on UDM / 132 the Loan Account and not the Agreement. FA_FA_BR0060: Contract Write-Off A loan for which all payments cannot be collected must be written off. (Additional business rules are required. Generic business rule for the loan lifecycle. For the generic solution believe this business rule is related to the Loan Account and not the Agreement Financial Agreement Management Entities and Attributes The following entities appear on the LDM for Loan Agreement Management; their descriptions can be found in other sections of this document. PARTY : see Section Party ACCOUNT: see Section Account PROJECT: see Section Work Effort Financial Agreement This entity maintains the set of specific terms, conditions and obligations that govern the relationship between a Financial Services organization and its customer(s) for a service provided. The FINANCIAL AGREEMENT defines the formal contract. Agreement ID PK Uniquely identifies the FINANCIAL AGREEMENT. Agreement Type ID FK Identifies the type of agreement. Product ID FK Identifies the Product for which this agreement is prepared for. From Date M The start date for the valid period of the agreement. Thru Date O The end date of the valid period of the agreement. Party ID From FK Identifier the from Party participating in the agreement. Party ID To FK Identifier the to Party participating in the agreement. Role Type ID From FK The role played by the from Party. Role Type ID To FK The role played by the to Party. Agreement Date M The date the agreement was prepared. Description M Free text, provides details regarding the Financial Agreement. Comments O Free text, provides additional information of interest regarding the Financial Agreement. Subtypes are: LOAN AGREEMENT INVESTMENT AGREEMENT.

106 Financial Services logical data model for Social Economy based on UDM / Agreement Type Stores the complete set of values allowed for the FINANCIAL AGREEMENT entity. Constraints Description Attribute Agreement Type ID PK Uniquely identifies an AGREEMENT TYPE. Added for Name M The value of the Agreement Type. Possible values are: Loan, Investment, and Savings Agreement Item Stores the various agreement items that detail a FINANCIAL AGREEMENT. Agreement ID PK, FK Identifier of the AGREEMENT that the AGREEMENT ITEM belongs to. Agreement Item PK Uniquely identifies the Agreement Item. Sequence ID Agreement Text M Free text, provides the Agreement Item details Agreement Term Stores the various types of agreement terms and conditions that apply to an AGREEMENT or to AGREEMENT ITEMs. Subtypes are: LEGAL TERM FINANCIAL TERM INCENTIVE TERM OTHER AGREEMENT TERM. Agreement Term ID PK Uniquely identifies the AGREEMENT TERM. Term Type ID FK Identifies the type of term the Agreement Term is. Agreement ID FK Identifies the Agreement the Agreement Term belongs to. Agreement Item FK Identifies the Agreement Item. Sequence ID From Date M The start date doe the valid period for the Agreement Term. Thru Date O The end date of the valid period of the Agreement Term. Term Value O The value or specifics of the Agreement Term.

107 Financial Services logical data model for Social Economy based on UDM / Agreement Term Type Stores the complete set of values allowed for the AGREEMENT TERM entity. Agreement Type ID PK Uniquely identifies the AGREEMENT TERM TYPE. Name M The value of the Agreement Term Type. Possible values are: Legal, Financial, Incentive, Other Agreement Role Maintains the roles that a Party plays in an AGREEMENT. Examples of roles are: Account Owner Account Co-owner Co-signer Party ID PK, FK Identifies a Party involved in the agreement. Agreement ID PK, FK Identifies the agreement. Role Type ID PK,FK Identifies the role the Party involved in the agreement plays Agreement Role Type Stores the complete set of values allowed for the AGREEMENT ROLE entity. Agreement Role Type PK Unique identifier for the AGREEMENT ROLE TYPE. Name M The value of the case status. Possible values: Account owner, account co-owner, Co-signer Asset Maintains items of value that are use to secure a FINANCIAL AGREEMENT. Subtypes of ASSET are FIED ASSET: for example: equipment, car, house INTANGIBLE ASSET: cannot be seen, touched or physically measured and their value is created through time or effort. Subtypes of INTANGIBLE ASSET are: o ESTIMATED INCOME o SECURITY (example: stocks, mutual funds, bonds).

108 Financial Services logical data model for Social Economy based on UDM / 132 Asset ID PK Unique identifier for the ASSET. Name M Free text, further describes the asset.

109 Financial Services logical data model for Social Economy based on UDM / Appendix D - Account Management 18.1 Account Management Feature List and Business Rules Following are some key features, extracted from the Lotus Notes application user guides and meetings with analyst. Note: No business rules are defined for this Functional Area. Feature AM_FA_FT15: Establish an Account for the Project AM_FA_FT20: Send data to Desjardins to disburse money Description For this is a process done outside the application software, manually. Further analysis is required to determine the various types of information required to establish an account for the different types of products/services offered by Desjardins. Also refer to Section 6 Financial Product Management. Once a request for a loan has been approved, the application system facilitates in the preparation of data and sends it to the Desjardins Transaction Express Services to disburse money into the appropriate account. Example of the type of data sent to Desjardins Transaction Express Service: customer name, Desjardins account number, transit #, and data amount. AM_FA_FT25: Prepare and send payments due data to Desjardins AM_FA_FT30: Display the history of Project transaction events The software application allows for the preparation of required payments for projects and transmits the data to Desjardins Transaction Express Service. The data may be prepared one month in advance of the actual payment due date Display a summary of financial transactions for a Project Account Management Entities and Attributes Account An account is the delivery mechanism for most financial product and services. This structure allows for the recording of all activities or transactions that a PARTY or Financial Services organization has performed in relation to the use of a product or service. Examples of subtypes are: LOAN ACCOUNT INVESTMENT VEHICLE ACCOUNT OTHER ACCOUNT.

110 Financial Services logical data model for Social Economy based on UDM / 132 Account Number PK Unique identifier for the ACCOUNT. Agreement ID FK Identifies the Agreement for which the Account was created. Description M Free text, provides details regarding the Account Loan Account A structure established to record all activity or transactions that a PARTY or Financial Services organization has performed in relation to a loan account. LOAN ACCOUNT is a subtype of ACCOUNT. Account Number PK Unique identifier for the ACCOUNT. Agreement ID FK Identifies the Agreement for which the Loan Account was created. Description M Free text, provides details regarding the Account. From Date M The start date for the valid period of the Loan Account Thru Date O The end date of the valid period of the Loan Account Account Status Maintains the various statuses an ACCOUNT has gone through including the most up to date status. Account Number PK,FK Identifies the Account. Status Type ID PK,FK Identifies the Status Type for the Account. Provides the status of the account. Status Date Time M The date and time the account status was last updated Account Status Type Stores the complete set of values allowed for the ACCOUNT STATUS. Status Type ID PK The unique identifier for the ACCOUNT STATUS TYPE. Description M The value of the account status type. Possible values are: New, Active, Under Review, Closed.

111 Financial Services logical data model for Social Economy based on UDM / Account Role Maintains the different roles a Party plays in the ACCOUNT. Account Number PK,FK Identifies the Account for which a Party has a role in. Party ID PK,FK Identifies the Party. Role Type ID PK,FK Identifies the Role Type of the Party for the account. From Date M The start date for the valid period of the role the Party plays in the Account. Thru Date O The end date of the valid period of the role the Party plays in the Account Account Role Type Stores the complete set of values allowed for the ACCOUNT ROLE entity Account Role Type ID PK The unique identifier for the ACCOUNT ROLE TYPE. Name M The value of the account role type. Possible values are: Owner, Joint Owner, and Guarantor Account Product An ACCOUNT may include more than one FINANCIAL PRODUCT which may be added or removed throughout the life of an ACCOUNT, hence the need for an ACCOUNT PRODUCT entity which identifies the FINANCIAL PRODUCTs that support the ACCOUNT and the effective dates of those FINANCIAL PRODUCTs (From date and Thru Date). For more details on FINANCIAL PRODUCT please refer to Section 6 Financial Product Management. Account Number PK, FK Identifies the Account. Product ID PK, FK Identifies the Financial Product. From date M The start date of the valid period for the Product for the Account. Thru date O The end date of the valid period for the Product for the Account Account Transaction Management Entities and Attributes Account Transaction An ACCOUNT TRANSACTION record is generated each time there is activity against an ACCOUNT.

112 Financial Services logical data model for Social Economy based on UDM / 132 Subtypes of ACCOUNT TRANSACTION are: FINANCIAL TRANSACTION, which has as subtypes: WITHDRAWAL DEPOSIT ACCOUNT FEE INTEREST ACCOUNT PAYMENT SECURITY TRANSACTION which has as subtypes: o BUY TRANSACTION o SELL TRANSACTION ACCOUNT REQUEST TRANSACTION which has as subtypes INQUIRY REQUEST CHANGE REQUEST SPECIAL REQUEST. Account Transaction ID PK Unique identifier for the ACCOUNT TRANSACTION. Account Number PK,FK Identifies the Account the transaction belongs to. Account Transaction FK Identifies the Account Transaction Type. Type ID Transaction Date M The date the transaction was submitted for processing. Post Date O The date the transaction was posted to the Account. Amount O The amount associated with the transaction Account Transaction Status Maintains current ACCOUNT TRANSACTION status and the history of the various statuses an ACCOUNT TRANSACTION has gone through. Account Number PK,FK Identifies the Account. Account Transaction ID PK,FK Identifies the Account Transaction. Account Transaction PK,FK Identifies the current status of the account transaction. Status Type ID Example statuses are: Posted, On Hold, Completed. Status Date Time M The date the status was last updated Account Transaction Type Maintains the complete set of valid values allowed for the ACCOUNT TRANSACTION entity. Account Transaction PK The unique identifier for the ACCOUNT TRANSACTION TYPE.

113 Financial Services logical data model for Social Economy based on UDM / 132 Type ID Name M The value for the Account Transaction Type. Possible values are: Withdrawal, Payment, Fee, Interest, Sell Security, Buy Security Account Transaction Task Maintains ACCOUNT TRANSACTION TASKs that need to occur at specific times; hence it has TIME FREQUENCY associated to it. Examples of ACCOUNT TRANSACTION TASKs are: POST TRANSACTION TASK: monetary transactions that cause an ACCOUNT credit or debit AUTHORIZED TRANSACTION TASK : monetary transactions that occur as authorized by the customer PRE-DETERMINE TRANSACTION TASK: pre-established transactions that occur at specific times (e.g. monthly). Account Transaction PK,FK Unique identifier for the ACCOUNT TRANSACTION TASK. Task ID Account Number FK Identifies the Account of the Transaction Task. Account Transaction ID FK Identifies the Account Transaction that created the Account Transaction Task Unit of Measure ID FK Identifies the Time Frequency which the Account Transaction occurs / performs according to. Task Creation Date O The date the Account Transaction was created. Requested Date O Specifies the date the Account Transaction Task was requested to be performed Description M Free test, provides further details regarding the Account Transaction Task Time Frequency Maintains the various possible rates of occurrences. Unit Of Measure ID PK Uniquely identifies the Time Frequency unit of measure. Abbreviation M The abbreviation for the unit of measure. Name M The actual value for the Time Frequency. Possible values are: Monthly, Annually, Weekly.

114 Financial Services logical data model for Social Economy based on UDM / Appendix E - Work Effort Management 19.1 Project Management Feature List and Business Rules Following are some key features, extracted from the Lotus Notes application user guides and meetings with analyst. Feature WE_FA_FT10: Establish a Project Description The system allows for a Project to be created. A Project allows for the management of a service to a customer. All activities, transactions, communication exchanges related to the Project are grouped under the umbrella of a Project. A unique project is created for each customer request for services. WE_FA_FT20: Link documents to a Project WE_FA_FT30: Capture and modify internal tasks related to a Project WE_FA_FT40: Display all task for a Project System allows for associating a document to a Project in the Document Management System. The system allows for the capturing and tracking of internal activities, which are not directly related to a customer. Allow for the possibility to assign a task to more than one person. The system provides a list of tasks for a Project indicating their status, who is expect to complete the task, the required by date and the person who assigned the task. Following are some key business rules, extracted from the Lotus Notes application user guides and meetings with analyst. The Notes column, are observations regarding the how the rules would fit into the generic model. Business Rules Description Notes A loan disbursement must only be issued once all disbursement preconditions are met. WE_FA_BR0010: Disbursement Preconditions are met Issue a notification once all disbursement pre-conditions are met. This business rule can be a generic business rule. WE_FA_BR0020: Notification of annual review The system must issue a notification that the annual rate review is due, 10 days before anniversary date of the disbursement. The number of days needs to be a configurable parameter.

115 Financial Services logical data model for Social Economy based on UDM / Work Effort (Account Notification) Management Entities and Attributes The PARTY entity appears on the LDM for Account Notification; its description can be found in Appendix Section Party Work Effort Maintains the ongoing efforts for activities that require resources and have start and end dates. WORK EFFORT Subtypes are: PROJECT NOTIFICATION TASK. Work Effort ID PK Uniquely identifies the Work Effort. Actual Completion O The date the activity completed. Date Actual Hours O The hours spent to complete the activity. Actual Start Date O The date the activity started. Special Terms O Free text, provides details regarding any special terms associated with the activity. Description M Describes the activity. Name M The activity name. Scheduled Completion O The planned date to complete the activity. Date Scheduled Start Date O The planned start date for the activity Work Effort Status Maintains current WORK EFFORT status and the history of the various statuses a WORK EFFORT has gone through. Work Effort ID PK,FK Identifies the Work Effort/activity. Status Type ID PK,FK Identifies the status for the activity. Status Date Time O Identifies the date the status was last updated Work Effort Status Type Maintains the complete set of valid values allowed for the WORK EFFORT STATUS.

116 Financial Services logical data model for Social Economy based on UDM / 132 Status Type ID PK Uniquely identifies the WORK EFFORT STATUS TYPE. Name M The value for the work effort status type. Possible values are: Open, Submitted, Cancelled, Closed Notification Task Maintains tasks associated with notifications to the customer regarding their accounts status and state. NOTIFICATION TASK is a subtype of WORK EFFORT. Subtypes of NOTIFICATION TASK are: INVOICING TASK STATEMENT TASK MARKETING TASK ALERT TASK OTHER NOTIFICATION TASK Internal Task Maintains pieces of work directed to employees of the Financial Services organization. Assigned to Employee ID FK Identifies the employee who is assigned the task Assigned by Employee ID FK Identifies the employee that assigned the task. Message O Free text, provides further details regarding the task Invoicing Task Maintains pieces of work associated with the process of notifying the customer about amounts due on an ACCOUNT Statement Task Maintains those pieces of work associated with the process of notify a customer about an account status and activities against the account. STATEMENTS are typically issued periodically according to an AGREEMENT Alert Task Maintains pieces of work that notify the customer of any possible problem or issue with the account, e.g. an account transaction error is detected, suspected fraud on the account or a delinquent loan account (payments not made on time).

117 Financial Services logical data model for Social Economy based on UDM / Marketing Task Store pieces of work associated with the process of notifying the customer of possible opportunities to improve their service, example solicitation for new products not currently used by the customer Other Notification Task Maintains pieces of work that require the Financial Services organization to contact a customer for purposes other than invoicing, statement, alert or marketing. Examples are: a past-due notification, a skip-payment option and a change in service on the account Account Notification Maintains results of NOTIFICATION TASKs which is issued to the customer. Subtypes: INVOICE see Section Invoice STATEMENT OTHER ACCOUNT NOTIFICATION. Account Number PK,FK Identifies the Account associated with the notification. Date PK The creation date of the Account Notification. Work Effort ID FK Identifies the Work Effort/activity. Message M Free text, provides additional details regarding the Work Effort / activity. Balance O The account balance at the time the Notification was created Internal Notification Maintains data regarding an INTERNAL NOTIFICATION. Account Number PK,FK Identifies the Account associated with the notification. Date PK The creation date of the Account Notification. Work Effort ID FK Identifies the Work Effort / activity. Assigned by Employee ID FK Identifies the employee who assigned the Notification. Recipient Employee ID FK Identifies the employee who is to receive the Notification. Message M Free text, Provides details regarding the Notification.

118 Financial Services logical data model for Social Economy based on UDM / Risk Analysis Feature List Following are some key features, extracted from the Lotus Notes application user guides and meetings with analyst. Note: No business rules are defined for this Functional Area. Feature AN_FA_FT10: Maintain a Risk Rating AN_FA_FT15: Create a notification for Risk Analysis due AN_FA_FT29: Display Risk Analysis Results Description Allow for the capturing and maintaining of a risk rating for a project. The types of information also to capture are: Allocation date of the rating Ratings scores o AA -Better than expected o A - Normal evolution o B -Slight difficulty o C- Difficulty o D -Significant deterioration o E -Liquidation Comments The system issues an to the analyst assigned to the project 1 week before the anniversary date of the loan disbursement to notify that a risk analysis activity is required for the project. Display the results of the risk analysis for project Risk Analysis Entities and Attributes Risk Analysis Maintains information regarding the risk analysis activity. RISK ANALYSIS is a Subtype of WORK EFFORT (not all its attributes are shown below, only those pertinent to RISK ANALYSIS). See Section Work Effort. Work Effort ID PK Uniquely identifies the Risk Analysis activity. Name M The name of the Risk Analysis activity. Description M The short description of the Risk Analysis activity. Scheduled Start Date O The planned start date for the Risk Analysis activity. Scheduled Completion Date O The planed end date for the Risk Analysis activity. Notes O Free text, provides further details regarding the Risk Analysis activity.

119 Financial Services logical data model for Social Economy based on UDM / Risk Analysis Subject Identifies the object of the RISK ANALYSIS, which is an ACCOUNT, PARTY or PROJECT. Work Effort ID PK Identifies the Risk Analysis activity. Risk Analysis Subject ID FK Identifies the target of the risk analysis, which could be PARTY, PROJECT or ACCOUNT Risk Analysis Subject Type Maintains the complete set of valid values allowed for the RISK ANALYSIS SUBJECT entity. Risk Analysis Subject Type ID PK Unique identifier for the RISK ANALYSIS SUBJECT TYPE. Name M The value for the Risk Analysis Subject Type. Possible values are: Party, Project, Account Analysis Outcome Maintains the result of the understanding or analysis of a risk analysis parameter. Work Effort ID PK, FK Uniquely identifies the Risk Analysis activity. Analysis Outcome ID PK Identifies a Risk Analysis sub activity, also known as, an Analysis Outcome. Risk Analysis Subject ID FK Identifies the target of the Risk Analysis, which could be a PARTY, PROJECT or an ACCOUNT. Risk Analysis Subject ID Type FK Identifies subject type of the target of the Risk Analysis. Analysis Parameter ID FK Identifies the risk analysis parameter. Analysis Outcome Score O Stores the result of the risk analysis parameter. Comment O Free text, provides additional details regarding the analysis outcome Risk Analysis Result Stores the overall risk assessment score as a result of evaluating a number of risk analysis parameters and their outcome. Work Effort ID PK, FK Identifies the Risk Analysis activity

120 Financial Services logical data model for Social Economy based on UDM / 132 Risk Analysis Subject ID PK, FK Identifies the target of the risk analysis, which could be PARTY, PROJECT or ACCOUNT. Assessment Date PK Identifies the risk assessment date. Score O Identifies the overall risk assessment score Parameter Type Maintains the list of values of factors to consider when conducting a risk analysis. Examples analysis parameters are: Credit history Repayment behaviour Late payments, missed payments Debt amount Asset level. Parameter Type ID PK Unique identifier for the PARAMETER TYPE. Name M The value for the Parameter Type. Possible values are: Credit history, Repayment behaviour, Late payments, Missed payments, Debt amount, Asset level, Project viability Analysis Parameter Stores the values for the factors considered during a risk analysis. The factors help to determine the outcome of the risk analysis. The factors may be weighted to establish which ones are the most critical or influential to the outcome of the risk analysis. Analysis Parameter ID PK Uniquely identifies a risk analysis parameter. Parameter Type ID FK Identifies the type of risk analysis parameter. Parameter Value O Provides the target value for the analysis parameter. Parameter Range O Provides a range for the analysis parameter. Analysis Parameter Weight O Provides the weight (importance or influencing factor) for the analysis parameter Budget Plan Feature List Following are some key features, extracted from the Lotus Notes application user guides and meetings with analyst. Note: No business rules are defined for this Functional Area.

121 Financial Services logical data model for Social Economy based on UDM / 132 Feature AN_FA_FT10: Prepare Budget Plan for a Project AN_FA_FT20: Export a Project Budget Plan into an Excel file Description The system provides a means to enter budget plan information for a project, which summarizes the project expenses and financing plan. The budget plan captures planned and actual figures. The system allows for exporting the budget information into Excel file where a user can update the information and save the updates Financial Plan Entities and Attributes Entities describe here in this section specific to not are based on the Universal Data Models Financial Plan Maintains the expenses and financing needed to achieve the objectives of a PROJECT. FINANCIAL PLAN is the supertype for: EPENSE FINANCING. Financial Plan ID PK Uniquely identifies the FINANCIAL PLAN. Project ID PK,FK Identifies the Project the financial plan is belongs to. From Date PK The start date for the period for which the financial plan is prepared for. Thru Date O The end date of the period for which the financial plan is prepared for. Description O Free text, provides further details regarding the financial plan Comment O Free text, provides additional information regarding the financial plan Financial Plan Type Maintains the classification of the FINANCIAL PLAN entity. Attribute Constraints Description Financial Plan Type ID PK Unique identifier for the FINANCIAL PLAN TYPE. Name M The value for the Financial Plan Type. Possible values are: Expense, Financing Financial Plan Status Type

122 Financial Services logical data model for Social Economy based on UDM / 132 Maintains the complete set of valid values allowed for the FINANCIAL PLAN STATUS entity. Note: the variance between planned and actual is a derived data attribute. Attribute Constraints Description Financial Plan Type ID PK Unique identifier for the FINANCIAL PLAN STATUS TYPE. Name M The value for the financial plan status type Possible values: Actual, Planned Expense Maintains the amounts for a project for items the fall under the category of cost of doing business which are used for generating revenues or creating goods and series. Examples of expenses are salaries, machinery depreciation, rent and utilities. EPENSE is a subtype of FINANCIAL PLAN Expense Item Maintains the detailed information for an EPENSE. Attribute Constraints Description Financial Plan ID PK,FK Identifies the Financial Plan. Financial Plan Type ID PK,FK Identifies the type of Financial Plan = EPENSE. Financial Plan Status ID PK, FK Identifies the status of the Expense Financial Plan. Expense Item Sequence ID PK Uniquely identifies the Expense (line) Item. Amount M The amount for the Expense (line) Item Financing Maintains the amounts for a project that identify the way needed funds or capital will be raised to meet the project objectives. FINANCING is a subtype of FINANCIAL PLAN Financing Item Maintains the funding amounts for a project. Attribute Constraints Description Financial Plan ID PK,FK Identifies the Financial Plan. Financial Plan Type ID PK,FK Identifies the type of Financial Plan = FINANCING.

123 Financial Services logical data model for Social Economy based on UDM / 132 Financial Plan Status ID PK, FK Identifies the status of the Financing Financial Plan. Financing Item Sequence PK Uniquely identifies the Financing (line) Item. ID Amount M The amount for the Financing (line) Item.

124 Financial Services logical data model for Social Economy based on UDM / Appendix F Invoicing and Payment Management 20.1 Billing and Payment Processing Feature List and Business Rules Following are some key features, extracted from the Lotus Notes application user guides and meetings with analyst. User Requirement feature list IC_FA_FT10: Prepare payment requests for each active project for the month and send to Desjardins IC_FA_FT20: Receive and apply payments received IC_FA_FT30: Display the payment schedule Description The system will facilitate the preparation of payments due for the month for each active Project, and send the information to Desjardins Transact Services. Payments may be: for principle and interest due and also any agreed upon fees. The system allows for the application of payments received against the project and generates an updated payment schedule. Display for a project an updated payment schedule. Following are some key business rules, extracted from the Lotus Notes application user guides and meetings with analyst. The Notes column, are observations regarding the how the rules would fit into the generic model. Business rules IC_FA_BR0010: Application of loan partial payment IC_FA_BR0015: Computation for Taxes In cases where only a partial loan repayment is received, apply the payment amount first to fees, then interest and the remaining payment amount to the principal amount. Business rules are required determine which products or services require the application of taxes. Business rules are required to determine the calculation formula for the application of taxes. Notes This business rule could be a generic rule. Tax rules will vary by Financial Services organization. Most likely taxes would be included as a feature of a Financial Product Invoicing and Payment Management Entities and Attributes

125 Financial Services logical data model for Social Economy based on UDM / Invoice Maintains the payments due for a specific period for products or services provided by the Financial Services organization. Invoice ID PK Unique identifier of the INVOICE. Account Number PK,FK Identifies the Account the Invoice belongs to. Invoice Date PK The date the invoice is issued. Description O Free text, provides details regarding the Invoice Message O Free text, provides additional information regarding the invoice. Invoice Due Date M The requested by date for the payment. Billed To Party ID FK Identifies the receiving Party of the Invoice. Sent to Contact Mechanism ID O Identifies the invoice destination contact mechanism (postal address or ) Invoice Type Maintains the classification of the INVOICE entity. Invoice Type ID PK Uniquely identifies the INVOICE TYPE. Name M The value for the Invoice Type. Possible values are: Loan Invoice, Loan Invoice Adjustment, and Guarantee Fee Invoice Invoice Item Stores the detailed information for a product or service for which the Financial Services organization is requesting payment for. Invoice ID FK PK Identifies the Invoice this Invoice Item belongs to. Invoice Item Sequence PK Uniquely identifies the Invoice Item within the Invoice. ID Taxable Flag M Boolean, indicates if the Invoice Item is a taxable item. Further analysis is required to determine where best to store this attribute. Item Description O Free text, provides details regarding the Invoice Item.

126 Financial Services logical data model for Social Economy based on UDM / Invoice Status Maintains current INVOICE status and the history of the various statuses an INVOICE has gone through. Invoice ID PK,FK Identifies the Invoice. Status Type ID PK, FK Identifies the status of the Invoice. Status Date PK Identifies the date the status was updated Invoice Status Type Maintains the complete set of valid values allowed for the INVOICE STATUS entity. Invoice Status Type ID PK Uniquely identifies an INVOICE STATUS TYPE. Name M The value for the invoice status type. Possible values are: Sent, Void, On hold, Payment Application Maintains the relationship that may exist between a PAYMENT and an INVOICE ITEM as well as between the PAYMENT and an ACCOUNT. Payment Application ID PK Uniquely identifies the PAYMENT APPLICATION. Payment ID PK, FK Identities the Payment. Account ID FK Identifies the Account for which this payment belongs to. Invoice ID FK Identifies the Invoice related to the payment. Invoice Item Sequence FK Identities the Invoice Item for which the Payment is applied to. ID Amount Applied M The amount being applied to the invoice item Account Payment Maintains the transfer of money from one PARTY to another PARTY. ACCOUNT PAYMENT a subtype of ACCOUNT TRANSACTION which is a subtype of FINANCIAL TRANSACTION. Subtypes of ACCOUNT PAYMENT are: RECEIPT (payment made from a customer to the Financial Services organization), represents incoming monies to an internal organization of the enterprise.

127 Financial Services logical data model for Social Economy based on UDM / 132 DISBURSEMENT (payment made from the Financial Services organization to a customer), represents outgoing payments of monies sent by an internal organization of the enterprise. Payment ID PK Identifies the Payment. Payment Type ID FK Identifies the type of Payment (Disbursement or Receipt). Payment Method Type FK Identifies the method used to make the payment. ID Party ID from FK Identifies the Party that issued the payment. Party ID To FK Identifies the Party that received the payment. Effective Date M The date when the payment can be realized, e.g. the date on a post dated check. Payment Ref Num M References a payment identifier such as a check number or electronic transfer id. Amount M The amount of the payment. Comment O Free text, provides details describing any circumstance involved in the payment transaction Payment Method Type Maintains the complete set of valid payment methods. Payment Method Type PK Uniquely identifies the PAYMENT METHOD TYPE. ID Name M The value for the Payment Method type. Possible values are: Electronic, Personal check, Cash.

128 Financial Services logical data model for Social Economy based on UDM / Appendix G - Mapping of SSFA entities to Universal Data Model Entities Subject Area SSFA Entity UDM Entity Notes People and Organization PARTY PERSON ORGANIZATION PARTY TYPE FINICAL INSTITUTION GOVERNMENT AGENCY LOCAL DEVELOPMENT FUND ENTERPRISE JOB STATISTICS PARTY ROLE PARTY ROLE TYPE CONTACT PRINCIPLE CONTACT EMPLOYEE INTERNAL ORGANIZATION CUSTOMER SUPPLIER PARTNER PARTY RELATIONSHIP PARTY RELATIONSHIP TYPE Contact Mechanism CONTACT MECHANISM TELECOM NUMBER ELECTRONIC ADDRESS POSTAL ADDRESS CONTACT MECHANISM TYPE PARTY CONTACT MECHANISM PARTY CONTACT MECHANISM PURPOSE PARTY CONTACT MECHANISM PURPOSE TYPE GEOGRAPHIC BOUNDARY CONTACT MECHANISM BOUNDARY GEOGRAPHIC BOUNDARY TYPE GEOGRAPHIC BOUNDARY ASSOCIATION GEOGRAPHIC BOUNDARY ASSOCIATION TYPE Communication COMMUNICATION EVENT Event FACE TO FACE COMMUNICATION EVENT PHONE COMMUNICATION COMMUNICATION EVENT PURPOSE COMMUNICATION EVENT PURPOSE TYPE COMMUNICATION EVENT STATUS COMMUNICATION EVENT STATUS TYPE CASE CASE ROLE CASE STATUS TYPE UDM entity name = Regulatory Agency Added Added Added Added

129 Financial Services logical data model for Social Economy based on UDM / 132 Financial Product FINANCIAL PRODUCT PRODUCT CATEGORY PRODUCT CATEGORY CLASSIFICATION PRODUCT FEATURE PRODUCT FEATURE APPLICABILITY FUNCTIONAL SETTING FUNCTIONAL SETTING APPLICATION Financial product FINANCIAL REGULATION Regulation and Rules REGULATION REQUIREMENT FINANCIAL PRODUCT RULE Financial Agreement FINANCIAL AGREEMENT AGREEMENT TYPE AGREEMENT ITEM AGREEMENT TERM AGREEMENT TERM TYPE AGREEMENT ROLE AGREEMENT ROLE TYPE ASSET Financial Account ACCOUNT LOAN ACCOUNT ACCOUNT STATUS ACCOUNT STATUS TYPE ACCOUNT ROLE ACCOUNT ROLE TYPE ACCOUNT PRODUCT ACCOUNT TRANSACTION ACCOUNT TRANSACTION STATUS ACCOUNT TRANSACTION TYPE ACCOUNT TRANSACTION TASK TIME FREQUENCY Work Effort WORK EFFORT WORK EFFORT STATUS WORK EFFORT STATUS TYPE NOTIFICATION TASK INTERNAL TASK Added INVOICING TASK STATEMENT TASK ALERT TASK MARKETING TASK ACCOUNT NOTIFICATION INTERNAL NOTIFICATION Risk Analysis RISK ANALYSIS RISK ANALYSIS SUBJECT Added RISK ANALYSIS SUBJECT TYPE Added ANALYSIS OUTCOME RISK ANALYSIS RESULT PARAMETER TYPE Financial Plan FINANCIAL PLAN FINANCIAL PLAN TYPE FINANCIAL PLAN STATUS TYPE EPENSE Added EPENSE ITEM Added FINANCING Added FINANCING ITEM Added Invoice INVOICE

130 Financial Services logical data model for Social Economy based on UDM / 132 INVOICE TYPE INVOICE ITEM INVOICE STATUS INVOICE STATUS TYPE PAYMENT APPLICATION ACCOUNT PAYMENT PAYMENT METHOD TYPE

131 Financial Services logical data model for Social Economy based on UDM / Appendix H French / English Terms French / Term activité de l'entreprise Adresse Civic apport chiffre d'affaires comite d'investissement commission d'engagement congés / délai de grâce conseil d'administration cote d'évaluation date d'affectation date de la cotation date de réalisation délai des paiements dons et subventions EQTP Équivalent temps plein fond de roulement honoraires de garantie honoraires de suivi immobilisations corporelles immobilisations incorporelles intervenants au financement matrice de prêt membre actionnaire périodicité prime de rendement remboursements révision annuelle du taux secteur d'activité suivi de prêt totales des dépenses réalisées totales du plan de financement type de fiche versement par année démarrage redressement prise de participation English (translation needs to be verified) business activity Civic address contribution sales Investment committee commitment fee grace period board of directors appraisal rating Posting date?? rating date realization date? delay payment Donations and grants Equivalent Full Time (EFT) working capital guarantee fees monitoring fees fixed or tangible assets intangible asses funding stakeholders loan schedule shareholder member periodicity performance bonus loan repayments annual revision rate business segment loan monitoring total expenditure incurred total financing plan Society Type payment per year start-up recovery equity

132 Financial Services logical data model for Social Economy based on UDM / 132 fusion merger