Skip to main content

Banking Industry : Too much complicated

I decided to write on this topic, as I work in one of the largest Bank in Australia and I realized that providing a banking solution is very complex. As the technology is growing so rapidly, that one can't afford to provide a complete solution using a finite set of technologies.  And these days, its a habit of Big software companies that they sell all their available products to their clients. They try to integrate all available tools to make a product. In Banking Software Bank also thinks that if many systems are communicating to each other in live environment, chances of fraud are minimized.

National Australia Bank is My Company's client. I personally feel that for a product like Next generation which is called as NGP in our terminology, still in developing state, is going to be a very great. As to provide such a testing environment to the product like NGP in its childhood days is not possible for small sector banks. But thanks to the testing team to test such a huge set of stack.

So, I landed here in Melbourne 6 months back, and when I look at the progress of our product in this span, I can imagine its complexity. As when I left Mumbai, I thought it just a matter of releasing our developed product here in Melbourne and it will be available for the Customers of the Bank to use it.

While writing those pieces of code, it seems too easy for simple transactions, but banking is not for those 90% simple straight forward cases, its about remaining 10% complicated cases, which looks so simple on paper, but when it comes to reality, so many permutation and combinations are applicable on those. For an end user, say ATM user, its just a matter of inserting his card into ATM machine, inputting PIN and amount to withdraw money. End user feel that his account is debited with the transacted amount. But is this which only happens in the system? No, since this is just a simple straight forward transaction, but it is also too much complicated.

Bank don't care about individual accounts for tracking balances because its not feasible, bank have ledgers which keeps a track of their money flow. A ledger can be as granular as an ATM machine, i.e. if bank wants to track balance flows from an ATM machine, then a ledger can be defined. Similarly, other parameters are defined, if more granular balancing is required. On the basis of these parameters bank plays with interest rates and other features to derive their business.

If I close my eyes and think of complex cases, too many transaction comes to my mind within seconds like, Interest calculations, Back dated transaction, reversal, force transaction on invalid account status, interest adjustments, tax calculations, tax adjustments, financial year closure, transactions beyond fin year, tax year etc etc. So, development happens for these cases always takes time. And these cases cannot be think of when we are developing. Since, when we are developing, we are only thinking of one scenario at a time, but in live environment these multiple complex cases can play a silent role in creating a big problem which we have missed during development. For a simple Debit transaction, there are 1000's of test cases.

Over and above all these complexity, security is another complex feature which need to be developed as part of such product. These days security is very crucial as the hackers spreading there network over internet in such a frequency that technology providers are worried about this.

After doing all this, if something happens in the system, then also, people have to think of the solution to bring the system to the normal. Banking looks simple from an ATM machine, but its too complicated from inside like wires in a telephone box which have infinite connections. Will be writing more on individual cases later.

Comments

Popular posts from this blog

Listener refused the connection due to NetExcepti​on

I was testing some piece of code for calculation of new date on the basis of a given pattern and the specified date. I wrote a method to automate the test cases to generates those patterns and calculate the new date for each date of the specified date of the range of years. Since there were around 1 million pattern test cases are possible, so I want to insert this data in database for any future reference. After creating a pattern I was inserting data of the pattern and the calculation date along with the calculated date. It was working fine. I was prepare to hit the start button now, after testing different patterns individually. I hit the run button and it started its executions, but in the middle, I got this error. java.sql.SQLException: Listener refused the connection with the following error:ORA-12516, TNS:listener could not find available handler with matching protocol stack       at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:4...

B*Tree Reverse index

B*Tree Reverse index is one of the index types that is supported by oracle. It more or less behaves like b*tree unique & non-unique index but only difference is the way it constructs the tree. In this index, index value is stored in the reverse direction when compared to the values in the actual data table. This index is used in order to distribute the index data evenly across all the leaf index nodes if table data is skewed very high. Like b*tree index, this index doesn’t understand NULL. This B*Tree Reverse index can be created on a single column or more than one column. More than one B*Tree Reverse index can be created for the same data table. HOW TO VERIFY: How to verify whether the created index is reverse index or not? Fire this query, select index_type from user_indexes where index_name = 'DEPT_ID_INDX' ð   This query would return “ NORMAL/REV ” (it means it is B*Tree index but of “Reverse” type) LITTLE-KNOWN FACTS TO BE REMEMBERED: ·      ...

Hash Natural Join

To perform hash join, Oracle follows these steps: 1.      Oracle chooses the smallest of two tables as the hash table (otherwise called as driving table). Oracle built the hash table in RAM after applying the hash function on the joining column(s) of the driving table. 2.      Oracle chooses the other [big] table as the probe table (otherwise called as driven table or probing table). It traverse through all the records of this probe table, applies the same hash function on the joining column(s) [column(s) used to join these two tables] and will hit the corresponding entry in the hash table. 3.      Oracle returns the output if a record from driving table is already present in the same hash key, else no record will be returned. It may look like Nested loop join & Hash join have the same architecture since both these have the concept of driving & driven tables but they have entirely different design if you closely look a...