Banks are extremely ordered organizations. One get to be like that when dealing with other people’s money and charging a retainer for those services, all while employing skilled workers on average wages.
Banking industry have evolved since the middle-ages in a very Darwinian way, so some of the risk mitigation procedures they have is work having a look at.
One of the leading banks in Israel have a very rigorous authorization scheme in which employees are given strict internal permits for various actions. For example if the teller had finished credit course stage IV, she was entitled to give credit up to a certain sum to certain clients.
The bank was interested in formalizing this authorization procedure and had asked us to design a governance system to enforce those rules.
Since banking industry is a mature and conservative industry, the IT is extremely heterogeneous and ranges from IBM mainframe to Unix based trading systems and up to Microsoft based clients and branch servers. So the rational was to implement a central engine that would expose an API to the core banking applications, allowing all verification to be done in one place and administered centrally. Core banking apps were required as part of the approving process by the risk controlling office to call the Authorization API during each business process that was controlled.
At first the design looked classical for an implementation of a rule based engine BRMS (Business Rules Management System), yet the organisation wasn’t keen on inserting yet another technology into its already large bag technologies so we were constrained to use existing legacy infrastructure.
Fortunately, a closer look at the administered rules and authorizations revealed that they had a very similar syntactic structure which implied a composite IF THEN ELSE sentences with numerical or enumerated constraints. This structure enabled us to implement the data structure on a relational DB (Sysbase) and implement the API as simple DAL calls to the database. The only user interface was an administrative one for entering the structure of the rules and constraints.
A notable mention was the hardware architecture that was designed to be fail-safe since most of the front office data-entry systems were dependent on the system performance. We also let failed timeout calls continue with pending authorizations.
