NZ Bank Account Validation

[Olwen Williams]

I used to know the check digit calculation used to validate bank
accounts, but can't remember it and have not been able to find it
on-line. Can anyone either refresh my memory or point me to some
documentation?

[anru chen]

http://pear.php.net/package/Validate_NZ/docs/0.1.0/Validate_NZ/Validate_NZ.html

php module.

[Olwen Williams]

Thanks, but that doesn't do the check digit calculations. And it looks
as if it might fail for banks who use 3 digit suffixes as well.
For those who don't know the check digit calculation multiplies each
digit by a weight and adds the lot together then does something with the
total divided by 10 or 11 and adds the final digit. There is a
calculation over bank/branch and bank/branch/account

> .
>

[te...@kiwireviews.co.nz]

That sounds far more like an ISBN code, than a bank account...

*********** REPLY SEPARATOR ***********

On 16/05/2007 at 7:04 p.m. Olwen Williams wrote:

>Thanks, but that doesn't do the check digit calculations. And it looks
>as if it might fail for banks who use 3 digit suffixes as well.
>For those who don't know the check digit calculation multiplies each
>digit by a weight and adds the lot together then does something with the
>total divided by 10 or 11 and adds the final digit. There is a
>calculation over bank/branch and bank/branch/account

---
Karl
www.KIWIreviews.co.nz - Where Your Views Count
P Please consider the environment before printing this email.

[Olwen Williams]

Most codes that have been around any length of time have check digits.
IRD numbers do, bank accounts etc. When I started programming we always
used check digits on customer numbers as well. It provides a sanity
check for transposed digits etc. The first program I wrote in my first
programming job print a list of valid check-digitted customer numbers.

[Cameron Junge]

That's what I was thinking... CC numbers use check digits, didn't think
bank accounts would.

I could be wrong, of course, just doesn't seem like the kind of thing
where you need a check digit. Would vastly reduce the number of
available accounts for a bank (even though with the combination of
branch & account number they have a huge amount available).

Cameron

[Olwen Williams]

Trust me that bank account numbers do. I phoned a friend who is a
programmer for a bank last night, and he is going to track down the
algorithm for me.

Some time ago now I worked on PC, and before that payroll systems. The
algorithm used dates back to the 1960's!!!

> .
>
>

[te...@kiwireviews.co.nz]

It would be really interesting if you could post the algo somewhere we could have a look at it... I know I am not the only one who is curious about it.

One of my clients is exploring the viability of a custom-designed e-tail module, and something like that would be a great 'peace of mind' feature to include.

Cheers...

*********** REPLY SEPARATOR ***********

On 17/05/2007 at 9:57 a.m. Olwen Williams wrote:

>Trust me that bank account numbers do. I phoned a friend who is a
>programmer for a bank last night, and he is going to track down the
>algorithm for me.

[Olwen Williams]

When I get it i think I'll propose a modification to that Validate_NZ
class. I'm probably going to do it in javascript as well so I'll make
that available too.

It is a great peace of mind thing. I think every one who writes payroll
systems uses it because it picks up the most common typing errors. Both
the branch number and the account number are validated.

[James McGlinn]

Hi Olwen,

Can you read Perl?

http://search.cpan.org/src/UNISOLVE/Business-BankAccount-NZ-0.02/NZ.pm

From the documentation:

The extent of the validation is simply that the account number is checked to ensure that it conforms with the notion of an account number laid out in the 'Bank Account Number Check Digit Validation Routines' brochure prepared by the Bank of New Zealand, dated 27 October, 1999.

Hope that helps,

James McGlinn

BCom, BSc, Zend Certified Engineer (PHP4, PHP5)

Director

Nerds Inc.

The Loft, 201 Hobson St, Auckland

(09) 377 5663 / (021) 633 234

http://www.nerdsinc.co.nz http://blog.phpdeveloper.co.nz

[Olwen Williams]

I can probably remember enough Perl. Thanks heaps.

[Olwen Williams]

Just received the code from my bank source. It's good that I can not
only read Perl, but Cobol as well :-)

[Michael Brandon]

I have a clients whm dedicated server that is down.

I have ssh access and whm access. Not sure how to get it back up - too many
connections. Can't kill connections, restarting mysql is not helping

Thanks
Michael Brandon

[Justin Cook]

The way users enter bank account numbers can differ greatly and be quite
confusing because the banks themselves can't agree on a basic standard
to adhere to. For this reason it's easier to enter your account in
backwards.

All you can do is verify certain parts of the account contain the right
amount of digits, and then verify the bank prefix is a real bank by
asking them "Is your bank ANZ", etc. The most common area for failure is
to move the first digit from the second number group into the bank
prefix, or vice versa.

[Olwen Williams]

I don't think it's that hard.
The bank is two digits, and I have a list of valid banks.
The branch is 4 digits
The account number is 7 digits and the suffix is 2 or 3 digits.
The bank code I have specifies valid suffix ranges for different banks,
but I think I'll ignore that.

All but a couple of banks use the same check digit validation over the
branch and account. Strangely enough my brother knew it off by heart
from his time as a computer operator for databank on the early 1970's.
For the account the weights are 0,10,6,8,4,2,1 and for the branch
6,3,7,9. Multiply the corresponding digit by the weight, and sum the
results. The answer has to be divisible by 11.
I thought there was another check digit on the bank/branch but it seems
that in this respect my memory was flawed.

When keying figures a common problem is transposing digits. This
algorithm traps that.

The banks that use a different calculation are a couple of smaller
banks. The Perl code has 4 but the bank code I got has only 2. They
are National Australia Bank, and Countrywide.
The missing ones from the bank routine are United bank which I think has
gone and the Reserve bank which I think does not have publicly
accessible accounts. Even government departments don't have reserve
bank accounts for everyday use. Westpac has a special branch to deal
with government banking.

[te...@kiwireviews.co.nz]

*********** REPLY SEPARATOR ***********

On 18/05/2007 at 8:09 a.m. Olwen Williams wrote:

>All but a couple of banks use the same check digit validation over the
>branch and account. Strangely enough my brother knew it off by heart
>from his time as a computer operator for databank on the early 1970's.
>For the account the weights are 0,10,6,8,4,2,1 and for the branch
>6,3,7,9. Multiply the corresponding digit by the weight, and sum the
>results. The answer has to be divisible by 11.

Most entertaining, running that algo over some of my bank account numbers...

I apparently have a faulty account... because one of the account numbers comes to 89! (unless 0*10 is treated as 1*10)

But thanks for that nice, plain-text summary of the algo... could really come in handy if I could get my head around my dodgy account number. After all, where there is 1...

Cheers...

[Olwen Williams]

The code is working now. I'll put it up as a class somewhere

[Byron]

If you want to contribute that to the Validate_NZ pear package
(mentioned in the 1st reply)

http://pear.php.net/package/Validate_NZ/docs/0.1.0/Validate_NZ/Validate_NZ.html

let me know off list

Rgrds

Byron

[Mark Paine]

I realize this is a very old thread, but this comes up on Google when looking for the routine, so I'll post an updated answer here.

Inland Revenue has a document which contains the correct algorithm, it can be found here:

https://www.ird.govt.nz/resources/d/8/d8e49dce-1bda-4875-8acf-9ebf908c6e17/rwt-nrwt-spec-2014.pdf

You need to lookup the Bank being used in this table to find which Algorithm to use...

Bank ID, Valid Branch Numbers, Algorithm 

01 0001 - 0999, 1100 - 1199, 1800 - 1899 * 

02 0001 - 0999, 1200 - 1299 * 

03 0001 - 0999, 1300 - 1399, 1500 - 1599, 1700 – 1799 , 1900 - 1999 * 

06 0001 - 0999, 1400 - 1499 * 

08 6500 - 6599 D 24 4300 - 4349 *

09 0000 E 

11 5000 - 6499, 6600 - 8999 * 

12 3000 - 3299, 3400 – 3499, 3600 - 3699 *

13 4900 - 4999 * 

14 4700 - 4799 * 

15 3900 - 3999 * 

16 4400 - 4499 * 

17 3300 - 3399 * 

18 3500 - 3599 * 

19 4600 - 4649 * 

20 4100 - 4199 *

21 4800 - 4899 *

22 4000 - 4049 *

23 3700 - 3799 *

25 2500 - 2599 F

26 2600 - 2699 G

27 3800 - 3849 *

28 2100 - 2149 G

29 2150 - 2299 G

30 2900 - 2949 *

31 2800 - 2849 X

33 6700 - 6799 F

35 2400 - 2499 *

38 9000 - 9499 *

*: If the account base number is below 00990000 then apply algorithm A, otherwise apply

algorithm B.

And here are the Algorithms

Algorithm Bank (2), Branch (4), Account (8), Base Suffix, (4) Modulo

A 0 0 6 3 7 9 0 0 10 5 8 4 2 1 0 0 0 0 11

B 0 0 0 0 0 0 0 0 10 5 8 4 2 1 0 0 0 0 11

C 3 7 0 0 0 0 9 1 10 5 3 4 2 1 0 0 0 0 11

D 0 0 0 0 0 0 0 7 6 5 4 3 2 1 0 0 0 0 11

E 0 0 0 0 0 0 0 0 0 0 5 4 3 2 0 0 0 1 11

F 0 0 0 0 0 0 0 1 7 3 1 7 3 1 0 0 0 0 10

G 0 0 0 0 0 0 0 1 3 7 1 3 7 1 0 3 7 1 10

X 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

(There are 8 digits above for Account number, and Algorithm C is the only one which uses the 8th digit. It's not in use apparently. There are 4 digits for suffix)


Example:

For the bank account number 01-902-0068389-00 algorithm A is to be used for validation. 

Weighted digits are 0 0 6 3 7 9 0 0 10 5 8 4 2 1 0 0 0 0

(0*0) + (1*0) + (0*6) + (9*3) + (0*7) + (2*9) + (0*0) + (0*0) + (0*10) + (6*5) + (8*8) + (3*4) + (8*2) + (9*1) + (0*0) + (0*0) + (0*0) + (0*0) = 176

176 / 11 = 16, remainder = 0 

I hope this helps someone,

Mark

[Brett Taylor]

I thought what was posted would be a good opportunity for learning some new stuff.

So I have started, albeit only just today, making a Composer package putting the IRD rules posted into a validating class. If any of you show interest in such a package, I will actually publish it.

In my travels though, I have found that our regular old bank account numbers form part of the BECS, Bulk Electronic Clearing System, administrated by PaymentsNZ, who publish a list of all the banks and branches in NZ:

http://www.paymentsnz.co.nz/clearing-systems/bulk-electronic-clearing-system

Combining this database and the IRD checksum rules should be a little fun. Maybe if the package user provides a copy of the text file, the library will consume it. I don't know yet. I'm just gonna go off of what the IRD has published, for now.

Brett Taylor

--
--
NZ PHP Users Group: http://groups.google.com/group/nzphpug
To post, send email to nzp...@googlegroups.com
To unsubscribe, send email to
nzphpug+u...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "NZ PHP Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nzphpug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Cristian]

Hi Brett,

Thank you for putting this together. I would be interested in such a package.

[Brett Taylor]

I have published my bank account validator on Github and Packagist:

https://packagist.org/packages/glutnix/nz-bank-account-validation

https://github.com/Glutnix/nz-bank-account-validation

Your issues, contributions and general feedback would be much appreciated, either here or at Github.

[Adam Henley]

> "Alternatively, download the contents of this repository into your project and require the class manually, like a caveman"

I laughed.