Profile

Sunday, July 20, 2014

The conceptual model for a bank: The Connection-pipe model



The main objective of this blog is to design a resilient core banking system. 

In any design exercise, it is helpful to use a conceptual model.  A good conceptual model allows us to simulate/predict behaviors under conditions that have as yet not occurred. For example in Physics the model of gravity allows us to predict what would happen if a projectile were thrown with a particular velocity. 

The fact that a model is able to simulate/predict means that the information about the system is “codified” into the model. This property is extremely useful in System design.  The implication of this is that if we choose a proper model then the system that we build based on that model will be much more comprehensive then if we were to build a system based only on the observed behavior of the system.  This is because the set of observed behavior would always be less then universe of possible behaviors that a system may be exhibited to display in future.

From the discussion in the previous section, a connection-pipe seems to be a good conceptual model for banking.  Banking, or at least what we have discussed so far of it, is nothing more then an agency that connects Providers of capital to Borrowers of Capital. Therefore the connection-pipe model seems an appropriate model for banking

In the subsequent sections as we delve deeper into the nature of banking we will continue to test whether the connection pipe serves as an adequate model.  We will continue to improve upon the model.  If at some point of time we find that it no longer serves the purpose then we will abandon it in favor of a better model.

To design core banking then is to design the “connection pipe” that connects the lenders and the borrowers. 

There are two degrees of freedom available in the design of this connection pipe
(1)         The way the pipe connects between the borrowers and the lenders
(2)         The nature of connection between the participants and the pipe

We call the first the Connection-path and the second the Connection-types

The greater the flexibility a system provides in setting up Connection paths and Connection types the greater the resilience of the resulting system.

Saturday, March 29, 2014

Banking. A raison d'être. Efficient Capital flows



Having defined the scope, Partitioning and the Primitivization techniques can now be used to start building the Retail banking system.  In this blog the word core banking is used for all of retail banking.  The two words are used interchangeably.

Partitioning is not really required as retail banking is not such a complex system.  Partitioning would have been necessary if either the system was complex or it was perceived to be complex because of limitations of domain knowledge.

Primitivization will be the primary technique used for designing the core banking system.  To recap Primitivization requires that we reduce he system to its core behaviors.   Identification of core behaviors require an exploration of the Primary need serviced by the bank i.e. the reason for which banks exist.

The starting point for building a resilient core banking system then is to explore the raison d’être’s of a bank.  History or rather the origins of the system (in this case banking) provides a useful starting point for understanding what fundamental need does a system fulfill.  This is because at the very beginning of the evolution, the functions that a system performs, caters only to the very essential needs. It is only with passage of time that the subsequent layers of sophistication, that obscure the essential purpose of the system, get added. 

If one looks at the origins of banking, the needs that a bank satisfies are of a simple kind. These are needs that arise early in a community that engages in commerce or industrial activity.

The essence of commerce is the exchange of value.  Often commerce started not with money but with barter as a fundamental tool.  Barter required a system to equate goods of different nature.  The practice of Barter introduced the fundamental concept of “value”.   It required for instance two bushels of wheat to be say equal in value to 1 bundle of silk. Such a system that worked on value-pairs could work as long as, the number of commodities traded were limited.  As the number of commodities multiplied the number of value-pairs to be maintained increased exponentially and made the system too complex to sustain itself. 

Burgeoning commerce led to the emergence of a standard measure of value, which in the early stages was often Grain or Silk.  All commodities were equated in value to certain amount of Grain or Silk.  This laid the foundation for emergence of Money as the store of value.  In due course of time different kings introduced their own coins that acted as a value store.  It was often the responsibility of the kingdom’s treasury to issue the coins.

This function of issuing of money is today performed by the central banks of the country. This is the essential function of the Central banks of the world.  I will build upon this in a later blog when I discuss how to design a resilient central banking system. The current blog is dedicated to building a resilient core banking system and hence I will return to the topic of commerce.

The creation of coins i.e. currency removed significant friction from trade. It allowed people to trade more easily. As the trade flourished, traders desired to expand their operations. Since the capacity to trade was limited to goods that one had, there was a natural desire to increase this capacity by borrowing. The advent of money allowed people to borrow from each other more easily and use that borrowing capacity to be deployed in trade.   

This fundamental need for borrowing is at the root of banking.  As trade flourished further, the process of borrowing capital from individuals became the constraint.  In response to this constraint emerged large lenders who had surplus money with them.

Commerce often resulted in surplus money with merchants from time to time.  So while on the one hand commerce related pockets of demand for money and on the other it created pockets of surplus money.  This surplus money sough both safety from theft as well as avenues for gainfully deploying that surplus.  The process of connecting pockets of demands with pockets of surplus money was not efficient when individual merchants became moneylenders.

Banks emerged in respond to the need for efficiently connecting the “surplus pockets” to “demand pockets”.  

This – the need to efficiently connect surplus pockets of capital with demand pockets – is the fundamental raison d’être for which a bank exists.

In the process of acting as a connector it serves two powerful needs of the economic being
(1) The need to borrow capital to embark upon enterprises beyond their means
(2) The need to seek a return on surplus capital

The Scope of the Blog



The scope of discussion for this Blog will be Retail banking

Wednesday, March 26, 2014

Core banking. Segmenting/Partitioning the Banking Space




Having understood that the main enemy of Resilience is complexity and having investigated the techniques of addressing complexity, it is time to apply these techniques towards our main purpose – the development of a resilient core banking system.

The first question in system design is always the scope – “What is the scope of the system being covered?”  This is a question that every system designer needs to confront right at the outset.

This question of scope best lends itself to analysis in a top down approach

The scope of a system is always defined in terms of the needs that it will cater to and the customers it will serve

The first question then for this blog is to address what should be the scope of the Core banking system that it will seek to cover.

The primary objective of this blog is to design a resilient core banking system.

A useful way to segment the banking “services/needs map is as given below. It identifies two kinds of customers – Individual or Corporate - and 2 kinds of needs – Transactions or Capital.  





The above Banking Matrix framework divides the banking space in to four different types of space: 
(1)Retail Banking
(2)Private banking
(3)Corporate banking
(4)Investment banking

Sunday, March 23, 2014

Primitivization and Inheritance Hierarchy. The technique for reducing Extrinsic Complexity



The second way to reduce Complexity is through a process that can be best named as Primitivization.

Primitivization is a process that allows us to cull out the common elements of all services.  By culling out common elements it reduces the number of programs where changes have to be applied when external conditions change.

Often there arises a confusion between the two techniques Primitivization and Partitioning .

Merriam-Webster dictionary defines Primitivization as the process of becoming Primitive

Wikitionary describes it as reducing something to a primitive state.

The word Primitive itself is defined as

“relating to, denoting, or preserving the character of an early stage in the evolutionary or historical development of something.”

In the context of complexity reduction of IT systems, primitivization means the technique of reducing the System to its most primitive state.   A system can be said to be in its most primitive state when it exhibits just enough behavior to be recognized as the pre-genitor of its more refined form.

A primitive system will exhibit only the core-behaviors. A behavior-set can be deemed to be “core” if all other behaviors that are exhibited by the more refined versions of the system can be derived from the “core behaviors”.   For example while a primitive version of a system may exhibit a behavior of emitting sound when subjected to a stimuli the more refined versions of it may emit different variations of sounds such as whisper, scream, etc when subjected to different stimuli.  Each one of the latter behaviors retain the property of “sound” but refine it through two modifiers – Intensity and Pitch.

The core behaviors are likely to be common across services.  So the process of identification of core behaviors is equivalent to yielding elements that are common across services.  It is this separation of common elements that leads to complexity reduction.

Primitivization is beneficial in another way.  Primitive systems are not complex and lend themselves well to design.  There is one problem though. Our real life systems are not primitive.  Therefore a technique is required to build more complex systems from the primitive system.  A technique called Inheritance hierarchy allows us to do just that. This technique of layering is called Inheritance hierarchy.  

Inheritance hierarchy is a technique that layers systems on top of one another with each layer building upon the previous layer. It is a technique that allows us to start with a primitive system and then build a hierarchy of increasingly complex systems with each hierarchy building upon the constructs developed in a layer below it.  Each layer in the hierarchy inherits the behavior from the system at a lower hierarchy and then introduces new functionality in that layer.  In each layer only that much functionality is introduced that is common to layers above it.  This hierarchical layering helps us reduce extrinsic complexity by identifying common service elements.

Evolution provides us a useful model to understand the technique of Primitivatization and inheritance hierarchy.   Each step in the hierarchy can be thought of as an evolutionary stage that inherits from the previous stage and build upon to it yield a higher-order system.  In the case of evolution of animals the primitive stage would be a bacteria and its most refined form, human beings.

To summarize Primitivization is the technique of building a primitive system first. Primitivization works by identifying common core behaviors.  Inheritance is the process of progressively building more complex behaviors on top of the primitive system. This technique works by progressively introducing elements that are common to layers above it.

Inheritance hierarchy extends the same approach with each subsequent layer introducing elements that are common to layers above it. In this system each child layer inherits the behavior and mechanisms of its parent layer.

To be precise then it is not just the technique of Primitivization but it is the technique of Inheritance hierarchy coupled with Pimitivization that leads to complexity reduction.  

Partitioning. The technique for reducing External (Intrinsic) Complexity





Partitioning as the name suggests is the technique of dividing the system into smaller parts. It is a fair assumption that each partition of the system is required to exhibit a smaller number of behaviors then the overall composite system. It is also a fair assumption that the smaller number of behaviors required of each sub-system will result in a less complex design for each system.

It is in this indirect way that Partitioning leads to a lower complexity.

It must be noted that partitioning imposes an integration cost on the system.  The partitioned systems need to be integrated with each other for the system to work.  This means that in effect, a two step hierarchy of systems is created. At the lower step are the individual partitioned systems each of which is made up of its own set of interacting elements. At the higher level is the system of these interacting partitioned systems.  

It needs to be noted though that Partitioning if improperly done can increase complexity. This can happen, if each sub-system provides similar services as a result of which there is need to create similar objects (programs) in each partition.

This technique works because each partitioned system being simpler lends itself to better comprehension and therefore better design.  

Saturday, March 22, 2014

Two Techniques for Complexity Reduction






Two techniques that help reduce this complexity are

(1)                      Partitioning technique that helps reduce the Intrinsic complexity
(2)         Primitivization and inheritance technique that helps reduce the extrinsic complexity

The principle used by both these techniques is divide and rule i.e. divide the system under consideration into smaller subsystems.