Confirmation of Payee - is it as poor for everyone else?

p00hsticks

colsten said:

Thrugelmir said:

dahj said:

Fingerbobs said:

BrownTrout said:

it only doesnt work with building society accounts where the accounts are one sort code and account number (so using a reference number)

It (sometimes) does work if you select the option for paying a "business" rather than an "individual" (or equivalent terminology) and enter the name of the Building Society as the recipient name.

It doesn't really help identify the end recipient as the account will be 'XYZ Building Society' where a roll/reference number is used. 

Building societies aren't clearing banks. 

Are you saying CoP only works with clearing banks? That would make it even more pointless than I think it already is.

I think the point dahj was making is that if you want to transfer money into your building society account, you only use the sort code and account number for the building society as a whole - the reference number that you enter (which should be the roll number of your particular account with the building society) is what tells the building society which of their internal accounts the money should be creditted too. The same applies when paying a utility bill - getting confirmation that the sort code and account number of the utility company is correct doesn't help you pay your particular bill if the reference number you enter is wrong, and there's no way the bank knows what it should be and so can't check it.

eskbanker

naedanger said:

eskbanker said:

naedanger said:
I think the banks were nitwits for using a customer operated system without check digits.

Given a sort code and account number structure that has been in place for decades, well before any customer operation was technically feasible, how would you have superimposed a check digit system without disproportionately extortionate wholesale changes to data structures and systems?

I would have recognised that a system suitable for one purpose is not necessarily suitable for another. 

Banks have layers of qualified staff checking details, and if they do make a mistake they find it much easier to correct. Often they can just go back and reclaim the money. Whereas a customer can struggle even to identify where the money went. Therefore it seems pretty obvious that just rolling out to customers a process designed for use by bank staff is going to cause new problems for their customers.

The system I would have introduced is to make the banks liable for correcting the consequences of any typing errors their customers make. If they don't want to pay the costs of developing new processes and systems then let them bear the liability for fixing the new problems that will inevitably arise. 

But that's still not actually coming up with any meaningful way of introducing check digit validation, but simply expecting financial liability for its absence to rest with the banks!

Anyway, that's all something of an academic distraction - the primary account validation method has been chosen and now (at least partially) implemented, based on existing data and structures, so hypothesising about alternative approaches that may or may not have been possible if they'd been considered much earlier isn't going to be particularly productive....

naedanger

eskbanker said:

naedanger said:

eskbanker said:

naedanger said:
I think the banks were nitwits for using a customer operated system without check digits.

Given a sort code and account number structure that has been in place for decades, well before any customer operation was technically feasible, how would you have superimposed a check digit system without disproportionately extortionate wholesale changes to data structures and systems?

I would have recognised that a system suitable for one purpose is not necessarily suitable for another. 

Banks have layers of qualified staff checking details, and if they do make a mistake they find it much easier to correct. Often they can just go back and reclaim the money. Whereas a customer can struggle even to identify where the money went. Therefore it seems pretty obvious that just rolling out to customers a process designed for use by bank staff is going to cause new problems for their customers.

The system I would have introduced is to make the banks liable for correcting the consequences of any typing errors their customers make. If they don't want to pay the costs of developing new processes and systems then let them bear the liability for fixing the new problems that will inevitably arise. 

But that's still not actually coming up with any meaningful way of introducing check digit validation, but simply expecting financial liability for its absence to rest with the banks!

Anyway, that's all something of an academic distraction - the primary account validation method has been chosen and now (at least partially) implemented, based on existing data and structures, so hypothesising about alternative approaches that may or may not have been possible if they'd been considered much earlier isn't going to be particularly productive....

No, it is a more sensible way of solving the problem than dictating one solution. The banks are in the best position to find the optimum solution. (I was just pointing out one solution that has been in existence for a very long time - check digits are used in plenty of existing applications.)

I agree there is no particular point hypothesizing about alternative approaches. But the option of making banks liable is still, in my view, an option to consider if they don't find a solution that works themselves.

colsten

p00hsticks said:

colsten said:

Thrugelmir said:

dahj said:

Fingerbobs said:

BrownTrout said:

it only doesnt work with building society accounts where the accounts are one sort code and account number (so using a reference number)

It (sometimes) does work if you select the option for paying a "business" rather than an "individual" (or equivalent terminology) and enter the name of the Building Society as the recipient name.

It doesn't really help identify the end recipient as the account will be 'XYZ Building Society' where a roll/reference number is used. 

Building societies aren't clearing banks. 

Are you saying CoP only works with clearing banks? That would make it even more pointless than I think it already is.

I think the point dahj was making is that if you want to transfer money into your building society account, you only use the sort code and account number for the building society as a whole - the reference number that you enter (which should be the roll number of your particular account with the building society) is what tells the building society which of their internal accounts the money should be creditted too. 

That's how it works for some building societies, or even for some accounts at some building societies. For example, Nationwide Building Society have a mixture of savings accounts with roll number, and some with sort code and account number. Coventry Building Society works with just sort code and account number. RCI Bank, despite being a bank, need a Reference number in addition to sort code and account number. So there's no simple, straight forward rule by which you could separate the payment formats for banks and building societies.

flo22

naedanger said:

eskbanker said:

naedanger said:

eskbanker said:

naedanger said:
I think the banks were nitwits for using a customer operated system without check digits.

Given a sort code and account number structure that has been in place for decades, well before any customer operation was technically feasible, how would you have superimposed a check digit system without disproportionately extortionate wholesale changes to data structures and systems?

I would have recognised that a system suitable for one purpose is not necessarily suitable for another. 

Banks have layers of qualified staff checking details, and if they do make a mistake they find it much easier to correct. Often they can just go back and reclaim the money. Whereas a customer can struggle even to identify where the money went. Therefore it seems pretty obvious that just rolling out to customers a process designed for use by bank staff is going to cause new problems for their customers.

The system I would have introduced is to make the banks liable for correcting the consequences of any typing errors their customers make. If they don't want to pay the costs of developing new processes and systems then let them bear the liability for fixing the new problems that will inevitably arise. 

But that's still not actually coming up with any meaningful way of introducing check digit validation, but simply expecting financial liability for its absence to rest with the banks!

Anyway, that's all something of an academic distraction - the primary account validation method has been chosen and now (at least partially) implemented, based on existing data and structures, so hypothesising about alternative approaches that may or may not have been possible if they'd been considered much earlier isn't going to be particularly productive....

No, it is a more sensible way of solving the problem than dictating one solution. The banks are in the best position to find the optimum solution. (I was just pointing out one solution that has been in existence for a very long time - check digits are used in plenty of existing applications.)

I agree there is no particular point hypothesizing about alternative approaches. But the option of making banks liable is still, in my view, an option to consider if they don't find a solution that works themselves.

Many banks DO already perform modulus checking on input 

naedanger

flo22 said:

naedanger said:

eskbanker said:

naedanger said:

eskbanker said:

naedanger said:
I think the banks were nitwits for using a customer operated system without check digits.

Given a sort code and account number structure that has been in place for decades, well before any customer operation was technically feasible, how would you have superimposed a check digit system without disproportionately extortionate wholesale changes to data structures and systems?

I would have recognised that a system suitable for one purpose is not necessarily suitable for another. 

Banks have layers of qualified staff checking details, and if they do make a mistake they find it much easier to correct. Often they can just go back and reclaim the money. Whereas a customer can struggle even to identify where the money went. Therefore it seems pretty obvious that just rolling out to customers a process designed for use by bank staff is going to cause new problems for their customers.

The system I would have introduced is to make the banks liable for correcting the consequences of any typing errors their customers make. If they don't want to pay the costs of developing new processes and systems then let them bear the liability for fixing the new problems that will inevitably arise. 

But that's still not actually coming up with any meaningful way of introducing check digit validation, but simply expecting financial liability for its absence to rest with the banks!

Anyway, that's all something of an academic distraction - the primary account validation method has been chosen and now (at least partially) implemented, based on existing data and structures, so hypothesising about alternative approaches that may or may not have been possible if they'd been considered much earlier isn't going to be particularly productive....

No, it is a more sensible way of solving the problem than dictating one solution. The banks are in the best position to find the optimum solution. (I was just pointing out one solution that has been in existence for a very long time - check digits are used in plenty of existing applications.)

I agree there is no particular point hypothesizing about alternative approaches. But the option of making banks liable is still, in my view, an option to consider if they don't find a solution that works themselves.

Many banks DO already perform modulus checking on input 

So there should be no excuse for the ones that don't.

That said, the digit checking system has to be one designed to be good at catching the type of errors humans commonly make when typing e.g. transposition errors.

schiff

Did a FP from Santander to Furness BS this morning, entered Furness Buiding Society (it's my only account with them so it doesn't need a special title), the sort code produced RSofS and there was no check of payee when I put the rest of the details in.
First time a payment to a BS using a clearing bank has gone through without a verification.  

Armorica

There is a digit check system already.  Some typos will still pass the mod check. So....

Nationwide is effectively a "clearing bank" (clearing bank is an outdated concept though).

The primary distinction is who is directly connected to things like Faster Payments and COP. And those who use sort-codes/customer account numbers vs. those still using roll numbers and reference fields. A handful of the larger building societies aren't using roll numbers for current accounts; but may still be for savings accounts. 

colsten

Armorica said:

The primary distinction is who is directly connected to things like Faster Payments and COP. And those who use sort-codes/customer account numbers vs. those still using roll numbers and reference fields. A handful of the larger building societies aren't using roll numbers for current accounts; but may still be for savings accounts. 

Nationwide have a seemingly random mixture of sort code/account number and roll number for their savings accounts. 

Armorica

colsten said:

Armorica said:

The primary distinction is who is directly connected to things like Faster Payments and COP. And those who use sort-codes/customer account numbers vs. those still using roll numbers and reference fields. A handful of the larger building societies aren't using roll numbers for current accounts; but may still be for savings accounts. 

Nationwide have a seemingly random mixture of sort code/account number and roll number for their savings accounts. 

Thanks - I've seen the industry guidance that sets out the relevant details precisely. I suspect some of it reflects the various building societies that Nationwide has bought over the years and accounts inherited from those organisations. (Including Portland, Cheshire, Dunfermline, Derbyshire)

The website also clarifies some of the rules - e.g. account number for savings accounts with a card, and e-savings; but roll numbers for those with a passbook and ISAs.