The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Simple Banking Solution

I am in a design phase of a simple banking solution for a local rural bank. As happens in a normal banking method, interest on deposits and loans is calculated half yearly or annually. For this I want to understand how to effectively apply this feature. I have thought of two options:

(1) As the application starts, the program will check for all the account holders to whom interest is to be applied. As it finds these records, it will apply the interest then and there.

(2) Whenever the account holder do any transaction, at that time check whether interest is to be given.

Please suggest how to manage this easily.
RK Send private email
Monday, November 05, 2007
 
 
Option (1) sounds slow -- how long will the user have to wait while interest is applied before he/she can use the program?  Option (2) sounds unreliable -- there's always the possibility that you'll enter the account in some other way and will forget to apply interest in that case.

I'm puzzled by the way you describe this application.  I'd think some component of it would be running all the time, and would apply the interest based on the current time, so that at midnight on the 1st of every month (or whatever) it would apply interest.  A banking application, where interest is compounded over time, doesn't seem like the sort of thing that should be started and stopped.
Kyralessa Send private email
Monday, November 05, 2007
 
 
"A banking application, where interest is compounded over time, doesn't seem like the sort of thing that should be started and stopped."

Nope. This is the normal model -- there's a program which puts the interest on accounts, and you run it from the scheduler (cron or whatever) at midnight every night.

Just like you have one which runs just before midnight that takes out all the standing orders. And then another one just after midnight which credits in the cheque data from the clearing centre... and so on.

It means that you don't have things running all the time (and therefore fighting each other) and you have nice linear steps, which are easy to demonstrate working and to debug, and, more importantly, can be recovered from.

If you have a DB failure and need to recover (say) last wednesday's data, you can do that and then just run all the same transaction programs again. And crucially; get the same result.

There are disadvantages to this sort of thing (you can't take less than a night to process deposits, for example), but the advantages mean banking software does fairly usually work in this way.
Katie Lucas
Monday, November 05, 2007
 
 
Our app is banking-related (securities) and we calculate interest once per month in a big batch job. I believe this is the case across most of our industry.

At one point we did it once daily (as Katie suggests), but this became way too cumbersome in light of backdated entries and corrections and so forth, and didn't really buy us much because accounts are typically only paid once per month anyway (at least, in our industry).

We also have a one-off "type in an account number, show me the interest to date" thingie that people use when an account is being closed and they need to calculate interest in advance of the regular monthly run.

My #1 piece of advice in this sort of app would be - remember to think about how to handle backdates and corrections. They tend to cause more problems than everything else put together.
Greg Send private email
Monday, November 05, 2007
 
 
Yeah, neither of those options is any good.

You will need a day-end, month-end, year-end, etc jobs that apply all of these updates.

It sounds like a homework question, as no bank would entrust their IT to someone who doesn't know how this stuff works.
Entries of Confusion Send private email
Monday, November 05, 2007
 
 
I don't know - where does "First National Bank of Spitsville, Kansas" normally get their banking software?  I imagine there are a lot of small, rural independent banks without sophisticated IT staffs.
Jason Send private email
Monday, November 05, 2007
 
 
@Jason:
I was probably a bit harsh saying it was a homework question, but I'm used to banking in the UK, where everything is big iron, lights never go out, kind of stuff.

The only exception to that is quick and dirty, high risk, hacking you might do for the traders on the desk.

In general, at least in the UK, stuff like this (ledgers, settlements, etc) is not done in a haphazard fashion. Of course, we don't have rural, independent banks here.
Entries of Confusion Send private email
Tuesday, November 06, 2007
 
 
"we don't have rural, independent banks here"

Doesn't the Royal Bank of Scotland count?
Arethuza
Tuesday, November 06, 2007
 
 
I thought all banking calculations and processes are highly regulated, and not something a programmer gets to decide?
Mac
Tuesday, November 06, 2007
 
 
I don't know about other places, but where I come from, capital and trading rules are highly regulated, but how you charge or pay interest is entirely up to you. You could use a random number generator and only pay interest on sunny days, if you felt like it. Though it might piss off some customers.
Greg Send private email
Tuesday, November 06, 2007
 
 
>> I am in a design phase of a simple banking solution for a local rural bank. <<

Have you done a buy vs. build analysis?

I know that IBM sold for many years a package called "Financial Branch System Services", and I think Hogan competes in this market, too.
xampl Send private email
Tuesday, November 06, 2007
 
 
There is so much wrong with this that I hardly know where to begin, so I will limit myself to one observation:
These are NOT decisions for the programmer to make.  Get the business requirements clearly defined or you will have a complete disaster.
Mikkin
Tuesday, November 06, 2007
 
 
+1 to Mikkin for that.
Entries of Confusion Send private email
Wednesday, November 07, 2007
 
 
"Doesn't the Royal Bank of Scotland count?"

Rural? It happens to be one of the biggest banks in the UK. I do use them, but am looking to switch because of their high charges (especially when processing US$ cheques). I'd hardly call them rural, though.
Ewan McNab Send private email
Wednesday, November 07, 2007
 
 
Banking software designed by someone who has to come here and ask how to do it?

People, our chains are being yanked so hard they may never come un-yanked again. There's no way that's for real - noone that ignorant of banking would be doing something like this.

And no, that optimisim injection half an hour ago didn't affect me at all. Why would you assume I'm being irrationally trusting?

Well, I certainly hope this is a joke - surely such software should have someone experienced in charge?

Wednesday, November 07, 2007
 
 
The rumors are true, Wal-Mart is getting into banking (and saving by not buying that expensive software.)

The answer is that you have to calculate a liability obligation when it is accrued.  How else could you accurately report your income statement, balance sheet or cash reserve requirements.  Also, can you imagine grandma with $10 million in the bank showing up for the first time in 5 years to withdraw a nickel and that transaction triggers the banks insolvency.
JBrooks Send private email
Friday, November 09, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz