Increasing Automation in Lending

Increasing Automation in Lending Roland Kaschek, Claire Matthews Catherine Wallace, Klaus-Dieter Schewe Massey University, Palmerston North, New Zealand [R.H.Kaschek|C.D.Matthews|C.M.Wallace|K.D.Schewe]@massey.ac.nz Abstract. Despite enormous potential to use web technology at the front-end of retail banking and the advent of mature respective development methodologies, the degree of web technology use in this banking sector is still low. In particular, this applies to lending which is the core of banking. In this paper we argue that there is a gap between the available conceptual means for employing web technology and the used ones. Fully exploiting the available means allows an increase in the degree of automation of loan processes and thus may help to introduce new business models.

1

Introduction

Technological advances such as the world-wide web provide a huge potential for financial institutions to change the way they deliver their products and services to their customers. However, the use of electronic products or service delivery has not advanced as expected [5]. In particular, this applies to the lending business. We believe that the degree of technology use at the front-end of retail banking can be increased if usage processes of these pages are modelled more completely. Capability to increase the degree of automation may help banks to redesign their business strategy and appearance on the market. Overall we concede that there are other aspects to be considered for this redesign issue such as tradition, widespread opinions concerning technology use in banking, or the respective bank’s profile and envisaged strategic market position. However, we neglect these and focus on technical ones, i.e., we restrict this paper to doability. We believe that the disappointing development of technology use in lending in part results from deficiencies of the applied development methods. A lot of work has been contributed towards sophisticated development methodologies for webbased information systems (WIS) (see e.g. [1, 2, 3, 4, 6]). Based on an analysis of the loan processing in several New Zealand banks we believe that despite the benefits of all these methodologies there is a significant gap between applicable and actually applied technology. Some development methods still do not satisfactorily guide developers concerning identification and mapping the business model to the logical model specifying the system under development. In [6] story boarding was used for this task. Story boarding focuses on obtaining the business model and the processes the WIS shall support. It requires identification and modelling of the various anticipated types of the bank’s customers. Finally, story boarding guides in defining the data (and views), the operations and dialogues customers are likely to use. Capability to increase the degree of automation clearly requires the respective information to be available. This paper addresses the mentioned gap in the lending area. A simple model of lending is provided. The lending process is discussed from a high level perspective that is applied by some New Zealand banks. In particular, we discuss the latitude left for for further automation and present an improved lending model. Finally we look closer at story boarding and apply it to lending.

Monitoring

Payment collection

Advance

Execution

Credit analysis

Business development

Origination

Servicing Funding

Monitoring

Fig. 1. A loan process

2

Lending

In a generic sense with lending one usually refers to that part of banking that results in assets as they are listed on the balance sheet. More specifically, lending refers to the banking that is based on loans, mortgages, bills of exchange or similar. Lending therefore is the core part of banking. Capability to increase the degree of automation potentially is thus of major importance. In particular retail banking, which is bulk business, could benefit from increased availability, correctness, accuracy, precision and speed as they would be expected to occur in automated business. According to [7] a loan is the “relinquishment of money or other fungible (...) properties connected with the obligation of the debtor to give back the relinquished in equal kind, quality and quantity.” A loan process here is understood as a model of how a loan is dealt with. 2.1

Loan Processes

Figure 1, according to [5], is an abstract representation of a loan process and indicates content and sophistication of models that are in fashion now in parts of banking in New Zealand. The process starts with the so-called ‘origination’, which in order of appearance consists of ‘business development’, ‘credit analysis’, and ‘execution’. In ‘business development’ as an intermediary step information inquiries may be issued by customers. After provisioning of product information to the customer a loan application may be issued to the bank. After that the bank must analyze these. Only those applications that likely result in profit for the bank should result in loans being granted. This, roughly speaking, is the case if a customer needs some money to bridge a liquidity bottleneck but in principle is solvent. This is assessed in ‘credit analysis’. Customers not already having an account with the bank should expect to open such an account if the application is approved. For these customers a solvency-check enquiry to the credit agency the bank favors will be generated. If the loan application is analyzed as likely to be profitable for the bank then the next stage ‘execution’ is entered and a loan contract must be designed. The respective design can either consist of using a standard contract, parameterizing a standard contract or working out an individual contract. In private residential mortgages one has to expect that either a standard contract is used or that parameters of a generic contract will be set to proper values turning the generic contract into a concrete one. The contract and several kinds of documents will in general be handed to the customer. These documents shall on the one hand ensure that the bank meets its

legal obligations concerning customer information. On the other hand the mentioned documents shall give the customer a better understanding of the actual state of affairs. This is likely to reduce all sorts of non forecasted customer inquiries to the bank while the loan is being amortized. The stage following the contract being signed is called ‘funding’. Signing the loan contract is the precondition for a credit position and a debit position being generated with respect to the customer. The credit position usually refers to a salary or cheque account (or similar) held by the customer. The debit position will refer to the loan account. The loan contract establishes an irrevocable automatic payment or direct debit from the borrower’s account to the loan account. Once the mentioned positions are generated the loan process enters the ’servicing’ stage and the collect payback process starts. This process goes on until the debit position is balanced which means that the loan is amortized. The collect payback will in general be performed automatically, as is the case with the monitoring of the payback. This includes detection of deferred paybacks and triggering respective manual activity. The high level view on the loan process taken in figure 1 does not address the actors carrying out the individual process steps such as ‘business development’, ‘credit analysis’ and the like. It further neither addresses the technical means used by the actors for this purpose nor the way the means eventually are used. In particular the way the actors coordinate their behavior is neglected. Additionally the diagram only vaguely addresses concurrency, though, e.g. ‘monitoring’ and ‘servicing’ overlap in time, they are represented in the diagram as occurring after each other. The diagram also does not address the economical factors to be optimized in the loan process. 2.2

An Improved Loan Process

An enhanced version of the loan process model is represented in figure 2 using a UML sequence diagram. It shows the actors in the loan process as the labels inside the rectangles at the top of the diagram. Dashed lines represent the life line of actors increasing from top to the bottom of the diagram. An arrow connecting two such life lines represents a message sent from the arrow’s source life line actor to its target life line actor. The arrow labels specify the message names and their parameters where required. The figure indicates concurrency of actors as their life line segments overlapping a given diagram level between an ingoing message and the outgoing message immediately following it. The bottom level rectangle containing the messages ‘Payback()’ and ‘CheckPayback()’ signifies that these messages are to be repeatedly sent until the stop condition signified by the asterisk and displayed below the rectangle ‘debit position balanced’ becomes true. One can use this diagram to group actors into organizations acting on the lending market. The respective business models can be determined by sets of actors and cooperation protocols. Some of these business models might not be feasible from the economic point of view. Complete automatization of the loan process is achieved if the activity in each organization is automatized and the data transferred between them by means of protocol conforming messages can be automatically extracted and used as input for the follow-up activity in the receiving organization. Automatization of the loan process thus requires the formats of the stored as well as the exchanged data to be known. Story boarding can be used for this end. 2.3

A Loan Application Scenario

Figure 3 describes a scenario of using an effective WIS (employing the language SiteLang; see [6] for more detail on it). The figure shows the online home loan application using a New Zealand’s bank

Marketer

Customer

Analyst

Lender

Service

Moniter

Accounts

ProductAd() Inquiry() RevisedProductAd() Application() ApplicationApproval() Notification()

Documentation()

Documentation() SignedContract()

SignedContract() AdvanceFunds() Start()

PositionsGenerated() UseLoan() CheckPayback()

*[debit position balanced]

Payback()

Fig. 2. An improved loan process Internet Banking Personal WIS view Home ASB Securities Index Commonwealth Bank Careers Home Loan Deal

Team New Zealand Adv & Link

Home page Welcome

Introduction Loans at a Glance Interest Rate Options Current Interest Rates Home Loan Calculators Home Buyers Guide Review your Home Loan Fixed Rate Expiry Move your Loan to ASB BANK Arranging a Home Loan Online Applications

Application type specification form Single application Home Loan

Home Loans Overdrafts Personal Loans Credit Cards Financing

Borrowing and Credit: Home Loans

Disclaimer

Accept Decline

Home Loan Rates First time Buyers Loan top up Contact Loan Enquiry Online Application Mobility Lending Manager

Applicant information

Life Events Under 25s Everyday Banking Borrowing and Credit Investments Insurance Travel, Foreign Exchange Business Banking Online Calculators Online Applications Information Centre Rural Banking Rates and Fees Cantact ASB Bank Join ASB Bank About ASB Bank

Submit Cancel

Submit Cancel

Income Committments Liabilities Assets

Fig. 3. Online home loan application scenario

WIS. Locations in the respective application space, so-called scenes, at which major customerWIS interaction takes place are represented as ovals. In general we labels scenes to name them but sometimes refrain from it. The arrows between scenes represent scene transitions. Scene transitions occur due to navigation or operation execution. Navigation functionality, data as well as operations, and advertisements respectively are represented as item lists in a rectangle, rounded box, or hexagon. The link, data or operation chosen by a customer in a scene is underlined. If advancing to the next scene requires several operations to be executed then all these operations are underlined. Denote the representation of list of navigation items N as N  . A dashed arrow from N  to R indicates that clicking on an item I of N leads to a refinement R of I being displayed. I then is underlined twice. The dotted lines connecting rectangles, rounded boxes and hexagons to scenes respectively show the navigation items, data and operations, and advertisements accessible

at the scene. The scene label showing that the depicted scenario is available for all customers is omitted. SiteLang allows a clear statement of the content, navigation functionality and dialogues accessible at a scene for users of a given type. It thus may help increase the degree of automation of loan processes towards a level at which only the recognition of the customer supplied data as valid and exceptional payment collection is done manually. This brief discussion of how story boarding can be applied in business development shows that it is to some degree possible, based on an understanding of the business, to anticipate the customers’ needs for accessing data, operations and navigation functionality. Extending this anticipation into a description allows employment of schema integration techniques for obtaining a consolidated representation of the data required as well as the derivation of views and access structures optimally supporting customers doing their job. Due to space limitations we do not go into more detail concerning this.

3

Conclusion

In the present paper we have discussed the approach to online loan application taken by some New Zealand banks. We argued that there is a significant gap between the possible and actual level of using web technology. We discussed how by following the story boarding approach a higher degree of automation of loan processes could be achieved.

References [1] Atzeni, P., Gupta, A., and Sarawagi, S. Design and maintenance of data-intensive web-sites. In Proceedings of EDBT ’98 (Berlin, 1998), LNCS 1377, Springer Verlag, LNCS 1377, pp. 436 – 450. [2] Ceri, S., Fraternali, P., and Paraboschi, S. Data-driven, one-to-one web site generation for data-intensive applications. In Proceedings of the Conference on Very Large Databases (VLDB 1999). IEEE Computer Society, 1999, pp. 615–626. [3] Feyer, T., Kao, O., Schewe, K.-D., and Thalheim, B. Design of data-intensive web-based information services. In Proceedings of the 1st International Conference on Web Information Systems Engineering (WISE 2000), Q. Li, Z. M. Ozsuyoglu, R. Wagner, Y. Kambayashi, and Y. Zhang, Eds. IEEE Computer Society, 2000, pp. 462–467. [4] Feyer, T. and Schewe, K.-D. and Thalheim, B. Conceptual Design and Development of Information Services. In Conceptual Modeling - ER ’98 (Berlin et al., 1998), Ling, Tok Wang and Ram, Sudha and Lee, Mong Li, Ed., Springer - Verlag Berlin Heidelberg, pp. 7 – 20. [5] Matthews, C. D., Kaschek, R. H., Wallace, C. M., and Schewe, K.D. IST in Lending: Unlimited potential but limited practice. Available from: http://cbs.dk/staff/lars.heide/ISTOS/program.htm, 2003. Paper presented at ISTOS Workshop in Barcelona, Spain, 28-30 March 2003. [6] Schewe, K. D., and Thalheim, B. Modeling interaction and media objects. In Proceedings of 5th Int. Conf. on Applications of Natural Language to Information Systems (Berlin, 2001), M. M´etais, Ed., Springer Verlag, LNCS 1959, pp. 313 – 324. [7] Wierichs, G., and Smets, S. Gabler Kompakt-Lexikon Bank und B¨ orse. Gabler Verlag, Wiesbaden, 2001.