Data & Analytics

A customer profiling framework for the banking sector

A customer profiling framework for the banking sector
of 19
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  Page 1 A Customer Profiling Framework for the Banking Sector  1   Benkt Wangler Sara Holmin KTH, Sweden {benkt | saraho}   Peri Loucopoulos Panos Kardasis UMIST, UK {pl | kardasis}    Giota Xini 01-Pliroforiki, Greece    Despina Filippidou Datel Advanced Ltd, UK     Abstract The European banking marketplace has recently undergone several changes that cause banks to re-engineer their processes and legacy information systems. The ultimate purpose of such projects is to enable better customer understanding, so that products and services are tailored to specific customer needs, and addressed to the right customer groups. As the solution to this challenge possibly lies within the masses of existing data, what lacks is the methodological support for structuring all this knowledge, and for ensuring that it is usable in modern banking practices. Such practices may vary from day-to-day operations, to complex knowledge discovery experiments. This paper reports on a research and development project that deploys enterprise knowledge modelling techniques for structuring, and re-using models of banking knowledge. The outcome of this work is packaged in the "customer profiling framework", being a set of patterns dealing with: (a) informational and organisational structures for the banking sector, (b) means and ends in knowledge discovery activities with specialisation to banking applications.   1. Introduction To keep and advance their competitive edge, companies of today need to individualise products and to approach every single customer in a particular way. This is usually referred to as "mass customisation" [Davids 1986] and "micro marketing". In his book on data warehousing, Sean Kelly [Kelly 1996] explains that customisation results in increased customer satisfaction and retention. Customisation requires, however, a profound knowledge of customers and their needs and habits (which applies not only to banking, but to almost every type of industry). Such knowledge would help companies to find answers to questions such as: •   Which customers would be interested in certain types of products and services? •   How would a product or service be designed so as to suit a particular customer, or a cluster of customers? •   How effective is the marketing on specific customers? •   Which attributes suggest that a certain customer cluster should be (or should not be) targeted with a new product or service? In order to acquire more knowledge about the customer (or in other words "to profile their customers"), banks need to take advantage of the information they already possess, i.e. to unveil 1  This paper was published in: Wangler, B., Holmin, S., Loucopoulos, P., Kardasis, P., Xini, G. and Filippidou, D. (1999)  A Customer Profiling Framework for the Banking Sector  , 9th European Japanense Conference on Information Modelling and Knowledge Bases, E. Kawaguchi, H. Kangassalo, H. Jaakkola and I. A. Hamid (ed.), IOS Press, Iwate, Japan, 1999, pp. 57-73.  Page 2 knowledge buried in their production databases, as well as to complement this with pieces of knowledge acquired from the outside world. A simple study of the transactions of a customer for example could reveal whether the customer has a saving or an expense policy, if he is often collecting information, or if he will have the chance to make a purchase in the future. Little concrete advice is, however, given concerning how to obtain this information, transform it and distribute it through internal company channels [Kotler 1994]. In any case, the utilisation of this knowledge brings about a number of interrelated challenges: in the regular banking operations (e.g. handling customer applications), in decision making (e.g.  product pricing, customer targeting), and also in the functionality of systems which maintain the aforementioned operations. Apparently, the banking market faces a need for change to which there is no simple solution. The complexity of the situation is due to the involvement of many different technologies, like business process improvement, legacy migration, data warehousing and data mining, which however have been used in isolation until now. The work presented here intends to deliver a framework which: •   Gives advice on how to reconcile any customer-related information derived from heterogeneous data sources on a single data model (naturally aiming at a single warehouse for a specific banking setting). •   Suggests what knowledge attributes may indicate high (or low) value of a customer, or of an agreement for a bank. •   Guides the improvement of the banking operations towards a state where customer profiling will be easier and more effective. •   Details the data mining process in such a way that bankers will be able to perform it with only little help from experts, and they will immediately apply the results in their work. •   Provides the necessary degree of formality for enabling the development of robust and flexible systems to support customer profiling. The way forward is to combine knowledge of banking conceptual structures, modern enterprise modelling methods, and ways of working in knowledge discovery in databases. The outcome of this technology integration is a set of generic (reusable) patterns dealing with the information structures of banking applications, the links of these information structures to typical banking operations, and their use in data mining experiments towards the discovery of knowledge useful in customer profiling. In order to enable a better understanding of what the customer profiling framework is, it is  probably necessary to refer to the things it is not. The following table is a briefing of that: A banking encyclopaedia Investigating the concepts of the banking sector has been a significant  part of this work. However, coming up with a complete and globally acceptable banking ontology has not been our principal aim. The users of the framework will only find concepts that appeared in our extended case study, and will need to customise them to their own  bank. Although it is difficult to guarantee completeness, the framework can ensure consistency when modelling a certain banking setting. The 10 commands on how banking  processes should be The customer profiling framework does not contain a complete set of  patterns of banking operations (e.g. customer application evaluation). In order to apply the customer profiling framework, the banking  Page 3 experts will need to depict their bank in terms of our modelling approach. It is our belief that it is easier to become familiar with a modelling approach through the examination of examples, than by studying a declarative manual. The derived models of the banking operations may or may not be similar to the suggested patterns. The  patterns will just introduce basic concepts (e.g. what is a business  process, and what it is not), and will demonstrate the modelling notation to be adopted. Data mining and data warehousing for dummies In order to create a data warehouse, users need to follow a number of steps, from the development of the necessary meta-data to the actual data extraction. It is impossible for any methodology to provide ready-made warehousing meta-data. The users will at least need to customise a data model according to their own data sources. Similar is the case with data mining exercises. Treasures found in other banks' data Data mining results heavily depend on the particularities of the application from which the data have been derived. That is, what is sound for one application may be wrong or irrelevant for another (e.g. the significance of a customer's marital status for their profitability will vary from one society to another). The presentation of patterns of data mining results aims at demonstrating how such results should be represented. The exact contents of the framework will be detailed in section 3. Section 2 is an introduction to the approach used for modelling the banking applications, namely the EKD approach. EKD has  been enriched with the concept of patterns, and has been extended in such a way that the results of the data mining operations can be depicted in a similar way with the existing enterprise knowledge. As a result, the user of the framework will be able to deal with the overall banking knowledge (developed or discovered) in a unified, consistent manner. Section 4 describes the ways of using the customer profiling framework. Finally, section 5 attempts to present similar approaches to the same problem, in the scope of comparing them with the approach presented here. 2. Background knowledge Business knowledge modelling is about describing in a formal or semi-formal way an enterprise with its agents, work roles, goals, responsibilities and business rules together with the technological infrastructure that supports the enterprise. Business knowledge modelling supports the strategic alignment task as well as the management of planning, evolution and change of  business practices and also of systems. It provides the means for describing the current structure of the enterprise, its missions and objectives. The impact of business knowledge modelling seems to be wide since its applicability is being considered in a number of different fields. Examples of such fields are business process re-engineering [Curtis, Kellner et al. 1992; Davenport 1993; Hammer and Champy 1994], enterprise integration [Goranson 1992; Petrie 1992], information systems development [Eriksson and Penker 1998], computer integrated manufacturing [Berio, Dileva et al. 1993; Kosanke and Vliestra 1989], and electronic data interchange [Lindencrona 1994]. There are a number of different methodological approaches to business knowledge modelling depending on one’s desired viewpoint. For example the Actor-Dependency model [Yu and  Page 4 Mylopoulos 1994] proposes a conceptual modelling framework which attempts to provide a systematic way of organising and using knowledge from multiple organisational analysis  perspectives; the M* methodology [Berio, Dileva et al. 1993] aims to assist designers in evaluating, planning and implementing changes in a CIM system; whereas the ORDIT approach [Dobson, Blyth et al. 1994] considers an enterprise in terms of work roles and responsibilities. Each methodology is suitable for solving problems in specific environments of certain cultures. The approach taken here (namely the EKD 2  approach) attempts to combine three different  perspectives: the organisational or intentional, the operational and the informational. Each of these perspectives is facilitated by one or more models and their graphical or textual notations. The development of the aforementioned models obeys to the constraints of corresponding EKD meta-models, which consist of a number of interrelated concepts, and whose purpose is to describe the enterprise and its universe in a consistent, correct and compete manner. The models used in EKD  address the following issues: (a) the objectives pertaining the AS-IS and the TO-BE enterprise situation, depicted in goal models; (b) the identification of actors, the roles they play, and the activities they perform as part of these roles, represented in actor-role and role-activity diagrams; (c) conditions and constraints of various types expressed in business rule statements; (d) information structures that facilitate the execution of enterprise operations, contained in  business object models. 2.1 EKD goal modelling Goal modelling is about describing the causal structure of a system (be it a business system, or a software system), in terms of the goals-means relations from the “intentional” objectives that control and govern the system functions to the actual “physical” processes and activities available for achieving these objectives [Loucopoulos and Kavakli 1995; Kavakli et al. 1996; Kavakli and Loucopoulos 1998]. The notation adopted to represent goal models is influenced by the notion of  AND/OR graphs used in problem-solving. According to this technique the goals are organised in a multi-level, more or less hierarchical goals-means scheme. 2.2 EKD role modelling Role modelling is about representing the organisational and behavioural aspects of an enterprise. This modelling perspective is concerned with the way business processes are performed through the involvement of enterprise actors in discharging the responsibilities and the interaction of their roles with other roles. An abstract view of roles, their interactions and dependencies, and the  principal objectives they satisfy are described in actor-role diagrams [Loucopoulos and Kavakli 1997]. A more detailed view of the activities in which roles are engaged is given by role-activity diagrams (RADs) [Ould 1995; Kardasis and Loucopoulos 1998]. 2.3 EKD business rule modelling Business rule modelling is about defining the constraints for enterprise operations, roles and  business objects. The term "business rule" is used to collectively express aspects of policy, standards, procedures, authorisation mechanisms and such like. The role of business rule modelling is twofold. Firstly, it is concerned with constraints placed upon information structures and with the derivation of new information based on existing information. Secondly, it is concerned with the eligibility for the execution of different activities and constraints placed on their order of execution. The EKD  approach supports a formal textual language to support the 2  EKD stands for "Enterprise Knowledge Development" and has been developed by UMIST (Prof. Peri Loucopoulos), by the Royal Institute of Technology in Stockholm (Prof. Janis Bubenko) and by PARIS-I SORBONNE (Prof. Colette Rolland) in the collaborative research projects F3, ELKD and ELEKTRA.  Page 5 expression of business rules. Rules are represented as a WHEN... IF... THEN…  statements [Martin and Odell 1992; Herbst et al. 1994]. The WHEN  part of a business rule will contain the triggering expression and the IF  part the preconditions for the invocation of an activity, or for the state change of a business object. 2.4 EKD business object modelling Its purpose is to describe the business objects that are required by the enterprise operations in order to fulfil their objectives, together with the logical relationships between these objects. The EKD approach provides a static view in business object modelling (definition of objects and associations) through class association diagrams [Rumbaugh et al. 1991]. 2.5 Enhanced models for knowledge discovery A knowledge discovery experiment consists of various knowledge discovery activities. Logically, the experiment is divided into several phases, which may be revisited according to new knowledge gained as outcome of the experiment, or provided by the bank's experts. The first logical phase would involve the dataset preparation. The second step deals with the selection of data records to be examined for hidden knowledge (data selection). Data mining is the actual knowledge discovery operation, which may be data clustering, data classification, or data visualisation. Data mining operations target at certain measures (e.g. 'profitability', 'risk', etc.). These measures are examined in terms of different data attributes, which may be found in or derived from the source data records. Data mining operations produce two different types of results: (a) data attribute dependencies, and (b) knowledge discovery rules. Both types of results reflect hidden relationships among the attributes of the bank's databases. The criteria for separating them deal with whether these dependencies can be quantified. Data clustering and classification result in expressions that can  be conformed to a unified expression format (IF… THEN… statements). For every knowledge discovery rule there is an associated degree of confidence and support [Clarke et al. 1998, Hyperbank Consortium 1998]. 2.6 The patterns extension Patterns capture the static and dynamic structures of solutions that occur repeatedly when  producing applications in a particular context [Coplien and Schmidt 1995; Hay 1996; Fowler 1997]. In order to ensure applicability and usefulness, patterns should: •   Define a problem together with the forces that influence the problem and that must be resolved. Forces refer to any goals and constraints (synergistic or conflicting) that characterise the problem. •   Define a concrete solution. The solution represents a resolution of all the forces characterising the problem. •   Define their context. A context refers to a recurring set of situations in which the pattern applies. Patterns consist of a body and their description [Rolland et al. 1998]. The former is a model that is effectively reused whereas the latter aims to describe the context in which the body of the  pattern can be reused. The template used for expressing a pattern body within the customer  profiling framework (i.e. the design metaphor) is that of EKD. The pattern descriptor is an aggregation of a signature and guidelines. The signature aims at describing the characteristics of a
Similar documents
View more...
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks