Capability 1.0. Basic Banking Model

Capability 1. 0

The capability being sought from the current version of banking model is very basic. It is only the capability to connect the need of the borrower to borrow a certain amount of capital to the need of the provider to provide capital with an expectation of a return. 

Object Identity. Framework for deciding Identity scope

Let us now enrich each of these objects by describing them a little bit more.  The way to describe an object is to identify and list out its attributes.

Let us start from our first object – the Person object.

A Person has a unique identity. Therefore for any Person (Provider or borrower) we should be able to uniquely identify him/her.  The person will have to have a set of attributes for this purpose and these can be collectively called “Identification” attributes.  It is reasonable to assume that one would need to communicate with the person and hence the object should also reveal the details that would permit effective communication to occur.

The Person object’s identity will then look as follows

(1)         Person

a.    Unique Identification

b.    Communication identifiers

Intuitively we all know that the object Person will have more identity elements that describe him/her such as his relationship quality with the bank, the degree of trust that a bank can place in him and so on and so forth. Each of the identity element provides a capability to the system.  Therefore the best way to flesh out the identity of an object is to start with a basic system and then progressively demand more capability of the system. Then in response to that demand add identity and behavior elements that help provide the capability.  

Hence before proceeding any further, it is appropriate that we state the basic capability that is being sought from the object model being developed in this section. This capability requirement provides a scope to our object model. In other words this capability requirement provides a basis for developing the objects in the object model. 

Once the basic object model has been developed, we would then progressively demand higher capabilities of the system. For each such demand we would incrementally add to the object model to deliver that capability

For each capability we would also enunciate the roles that each object would be expected to perform in order that the system can deliver the capability expected of it. The role definition are an essential intermediate step to developing the object identity and behavior.

This would be the approach that we will use to design our core banking system.

Object Model: The basic objects in our model

7 nouns (distinct objects) that are immediately visible are

(1)         Provider Person

(2)         Borrower Person

(3)         Provided Capital

(4)         Borrowed Capital

(5)         Provider Pool

(6)         Borrower Pool

(7)         Connection

In the above list compound nouns have been used for some of the objects.  The rules that we defined stipulate that in case in our model there are objects with compound nouns and if a part of the compound noun is common amongst two or more objects then a new object must be created.  Applying this rule, the new object model will have the following objects

(1)         Person

(2)         Provider Person

(3)         Borrower Person

(4)         Capital

(5)         Provided Capital

(6)         Borrowed Capital

(7)         Pool

(8)         Provider Pool

(9)         Borrower Pool

(10)     Connection

Resilient Object Model. Rules for Identifying Objects

The question then is how does one identify objects such that each object has a unique capability. The trick to identifying such objects is to look at the vocabulary of the conceptual model and look for Nouns. Each noun connotes a distinct capability.

When the vocabulary of conceptual model uses compound nouns then the above rule for identifying objects needs to be modified a little bit.  A compound noun is usually of the form Adjective + Noun (example Pink ball) or Noun + noun (Tennis + Shoe). 

Let’s illustrate as to what is to be done, in these cases, through the example of two objects - Tennis shoes and Football shoes. Both of these objects share a noun – shoes. A commonality of nouns would imply that the two objects share some common capability. Our rule for objects is that there should not be any overlap of capabilities between different objects.  Hence there is a case to split the object 3 ways – Shoes, Tennis shoes and Football shoes. As explained in previous section the object Tennis shoes as well as Football shoes will inherit the common capability of shoes from the object Shoes.  In such an arrangement of objects if a change were to be made in the capability of shoes then it will need to be done in one place only, namely in the object called Shoes.

Resilient Object Model. Governing rule for Objects

Object model requires us to identify the key objects, their identities and their behavior.

In the design of a Resilient System, the governing rule for objects is that each object should deliver a capability that is distinct from other objects. If two objects – Say object A and object B - have common overlapping capabilities then a separate object, object C, should be created for the common overlapping capability.  Both object A and object B would acquire the capability of object C through inheritance. It is assumed that the reader understands the concept of inheritance.

This method of identifying objects creates an Object model that is resilient in the face of change. Such a system is resilient because with no duplication of capability across objects, any one particular change is localized to only one object and does not have to be repeated across objects. This containment of changes is what helps the system remain resilient and cope with the change

Object Model. The Preferred representation for a Logical Model

There are many ways to represent a logical model.  The model preferred by me is the Object model. Other possible choices include Entity-Relationship diagram. 

Conceptual Model versus Logical Model

We have so far elaborated a part of the connection-pipe model.  The second attribute, the connection-type, still needs to be elaborated.  At this time, we could continue to elaborate the model or choose to move, whatever we have described so far, one step closer to a design format that can be more easily digitized.

I think it will provide a better understanding if instead of further elaboration of the conceptual model we move the discussion towards how to digitize the model developed so far.

Digitization means coding some logic.  The logic needs to be represented in some format before it could be coded.   Without the aid of an appropriate model for representing the logic it is quite likely that the code that will be developed may not be complete i.e. it may not cover all possible scenarios.  While we call the previous model (connection-pipe) a conceptual model we will call this class of model as “logical model”

A conceptual model helps us model the real life scenario so that we are able to go beyond the observable behavior and predict behavior that has as yet not occurred. 

A logical model on the other hand ensures that the conceptual model that we have developed is represented in a way that all the interactions conceived in the conceptual model are captured COMPLETELY.

The purpose of a conceptual model is to completely describe the real life BEHAVIOR.  The purpose of the logical model is to ensure that all the interactions possible in the conceptual model are completely described.  

Modelling a bank. Connection Paths

Having decided upon connection-pipe as the conceptual model, let’s start fleshing out the details of this model.  This section elaborates the connection-path attribute of our conceptual-model.

Connection path as the name suggests is the pathway that connects the borrowers and providers (lenders). There are a few possible pathways and I discuss these below.

(1)      Capital providers are directly connected to specific borrow request.  There are 4 subtypes possible

a.    One capital provider funds one borrower requests

b.    One capital provider funds many borrower requests

c.    Many capital providers together fund one borrower request

d.    Many capital providers together fund many borrower requests

This type of connection yields the Peer-to-Peer lending model of banking.

A pictorial depiction of these 4 cases is presented below

Type 1.d is the most generic one and if the system design implements type 1.d then all other are automatically implemented.  The job of the system design then reduces to implementing type 1.d

(2)         There is no direct connection between capital providers and borrowers.  The capital of all borrowers is pooled together and borrowers are distributed money from this pool.

This is the most common form of banking that is practiced.  However, this is the not only form as the subsequent pathways show.

A pictorial representation of this most common pathway is shown below

(3)         Providers and borrowers are connected through a common pool of funds that is distinguishable from all other pools. As in type 1 before there are 4 possible subtypes

a.    One capital provider pool one borrower pool

b.    One capital provider pool many borrower pools

c.    Many capital provider pools together fund one borrower pool

d.    Many capital provider pools together fund many borrower pools

A visual representation of these four pathways is given below.

Type 3 cases are the more generic versions of their corresponding type 1 cases.  In fact if the design of a system caters to type 3 cases then the corresponding type 1 cases are automatically implemented.

Type 3.d is the most generic one and if the system design implements type 3.d then all other type 3 (and type 1) are automatically implemented. 

Not only type 1 cases but also type 2 case is a specific implementation of a type 3 case where there is just one provider pool.  

The job of the system design then reduces to implementing type 3.d

(4)         In the 4^tht pathway the bank acts as intermediate processor to convert money given by producers to “businesses” that borrowers want to invest in. 

This is actually the Islamic banking model where bank is not allowed to lend money to borrowers (or rather not allowed to charge interest to them) but can assume joint risk or charge fees for services provided.

A visual representation of the pathway is given here

This is the most generic version of all the pathways discussed so far.  A design that implements this pathway will be resilient.  It provides for any form of business model that one can foresee into future.

It provides for Peer-to-Peer lending, Islamic banking as well as traditional Retail banking.  It goes beyond all of these and allows for models of banking where providers can choose what form of assets should their capital be deployed towards and allows them to earn returns commensurate to the risks that they are willing to take.