Credit union paid to different account (not mine)

The only time I have encountered a problem and maybe that no longer exists now that UB is gone as maybe the system was specific to them was when I sent money to the right account number and wrong sort code. I had accounts in two different UB branches so had two sort codes and I quoted the wrong account number with the non matching branch sort code. It went through to someone else's account. Turned out UB reused their account numbers across branches so if you got a sort code wrong as in a correct sort code but for the wrong branch then there was a risk it would hit a valid account combination but not necessarily yours!

There were 7 branches in the country that had that particular account number so getting the right sort code was vital! Those new checks should catch that though as name would be different.
 
Monbretia said:
The only time I have encountered a problem and maybe that no longer exists now that UB is gone as maybe the system was specific to them was when I sent money to the right account number and wrong sort code. I had accounts in two different UB branches so had two sort codes and I quoted the wrong account number with the non matching branch sort code. It went through to someone else's account. Turned out UB reused their account numbers across branches so if you got a sort code wrong as in a correct sort code but for the wrong branch then there was a risk it would hit a valid account combination but not necessarily yours!

There were 7 branches in the country that had that particular account number so getting the right sort code was vital! Those new checks should catch that though as name would be different.
Click to expand...
That's impossible now as all payments just use the IBAN and the sort code is built into the IBAN. I'm fairly sure it goes Country Code-CheckDigits-BIC-OldSortCode-AccountNumber.
 
Freelance said:
The destination bank will send a response (e.g. match, no match, close match, check not possible).
Click to expand...
Perhaps OT but I wonder how this will play out in practice, particularly for businesses.

A lot of businesses accounts don’t use their trading name or use the name of the proprietor. Not to mention many married women still have an account in maiden name.

A lot of payers could end up making false rejections of legitimate transfers as they will get a warning that the payee name doesn’t match what they’ve entered.
I hope there’s some kind of effort to clean this up in advance of account verification.
 
Monbretia said:
The only time I have encountered a problem and maybe that no longer exists now that UB is gone as maybe the system was specific to them was when I sent money to the right account number and wrong sort code. I had accounts in two different UB branches so had two sort codes and I quoted the wrong account number with the non matching branch sort code. It went through to someone else's account. Turned out UB reused their account numbers across branches so if you got a sort code wrong as in a correct sort code but for the wrong branch then there was a risk it would hit a valid account combination but not necessarily yours!

There were 7 branches in the country that had that particular account number so getting the right sort code was vital! Those new checks should catch that though as name would be different.
Click to expand...
This can't happen any more since sort codes have been done away with.
 
Dr Strangelove said:
Perhaps OT but I wonder how this will play out in practice, particularly for businesses.

A lot of businesses accounts don’t use their trading name or use the name of the proprietor. Not to mention many married women still have an account in maiden name.

A lot of payers could end up making false rejections of legitimate transfers as they will get a warning that the payee name doesn’t match what they’ve entered.
I hope there’s some kind of effort to clean this up in advance of account verification.
Click to expand...
Isn't this really up to the customers?

The lesson here is that, if you're giving your bank account details to someone so that they can make a payment into your account, make sure the name you give them corresponds to the name on the account.

If you're carrying on a business under one name, but operating it using a bank account in another name, maybe stop doing that?
 
TomEdison said:
If you're carrying on a business under one name, but operating it using a bank account in another name, maybe stop doing that?
Click to expand...
I agree. I know of one firm with a well-known trading name collecting thousands of direct debits monthly with the proprietor’s full name appearing on all of the transactions. It’s daft.

But there are systemic issues here about trust in the SEPA payments system that are bigger than individual businesses. Naive people (of which there are many) could be turned off EFT as a means of payment if they frequently get these messages warning them of a non-match.
 
Dr Strangelove said:
But there are systemic issues here about trust in the SEPA payments system that are bigger than individual businesses. Naive people (of which there are many) could be turned off EFT as a means of payment if they frequently get these messages warning them of a non-match.
Click to expand...
Sure. But the people primarily disadvantaged by this are not the payors; they're the payees. They're the ones who lose out if payments are held up, diverted or not made at all.

And they're also the ones who are best positioned to sort this out through the simple measure of not conducting different aspects of their business under different names. If the invoice says Bloggs & Co then the bank account to which payment is to be made should be in the name of Bloggs & Co. This isn't rocket science.

My bank may not know that I'm sending out invoices under the name of Bloggs & Co, so it's unreasonable to expect them to approach me and suggest I rename my account to match. But I know that I'm doing that, and if I can't be arsed to sort the mismatch out then it probably won't get sorted out.
 
TomEdison said:
But the people primarily disadvantaged by this are not the payors; they're the payees. They're the ones who lose out if payments are held up, diverted or not made at all.
Click to expand...
Of course. The issue will self regulate to some extent. But there is a broader issue about ease of use of the SEPA infrastructure.

By way of analogy if 5% of dialled numbers put you through to the wrong person you’d hesitate to make phone calls.
 
Monbretia said:
Are they no longer part of the IBAN? Has the format of it changed or is changing.
Click to expand...
There is no longer a system of directing payments using sort codes. The IBAN is a unique identifier for each bank account. Banks that previously used sort codes have incorporated those codes onto their IBANs, but standalone sort codes are no longer a thing.
 
Is it not possible to make a mistake in the IBAN and accidentally put in a valid number?

So if the number is

IE35AIBK 931063 12345678

And I put in

IE35AIBK 931063 13245768 Could that not be a valid number?

Or is it that what is effectively a 14 digit account number, if I make a mistake, the chances of it being a valid number are vanishingly small?
 
I would have thought my error could still occur, now mind you small risk and it would be customer error as if I was quoting the IBAN and I put in what used to be the sort code which is incorporated in the IBAN now cos there are several of them in my head memorised then if the UB system was still in place I could hit a valid account in another branch, no?

As in example above when I read IBANs in my head I split the 93-10-63 as I remember them when they were sort codes so what if I put in 93-62-19 with my correct account number is there a chance that will hit a valid account in AIB Tralee or is there only one usage of an account number anywhere in the country?
 
There's some information about how IBANs are checked/validated here:

IBAN Suite: Validation & Calculation Service

IBAN Suite providing fast and reliable payment validation for IBAN payments. Implementing IBAN validation in the input of your payment management system, CRM, ERP or finance software
www.iban.com
E.g.:

2. IBAN Check Digit​

Integrity check on the IBAN using ISO 7604 (MOD 97-10) algorithm is performed at this step.
Click to expand...

ISO/IEC 7064 - Wikipedia

en.wikipedia.org en.wikipedia.org
 
Dr Strangelove said:
Perhaps OT but I wonder how this will play out in practice, particularly for businesses.
Click to expand...
It will be very interesting to see how it plays out. Apparently it applies to batch transactions as well as online/interactive. So think of a large accounts payable batch of payments being submitted (with all the wrong names as has been pointed out here). Or the first time a large Paypath payroll batch is submitted. Ireland is particularly vulnerable, given the cavalier attitude the banks have had into name checking on cheques and allowing virtually any name on a cheque to be lodged, even when crossed. The British banks were always far tighter on this. To add to the concerns, Verification of Payee is being implemented on a very short/tight timeline. The rulebook was only published in October 2024. So it could be a bumpy ride. But is definitely necessary given the huge volume of online/interactive/realtime transactions, especially with the onset of SEPA Instant which is a game changer. But also worth considering that SEPA has been well managed and quite successfully rolled out so far.

More on Verification of Payee here
 
Brendan Burgess said:
Is it not possible to make a mistake in the IBAN and accidentally put in a valid number?

So if the number is

IE35AIBK 931063 12345678

And I put in

IE35AIBK 931063 13245768 Could that not be a valid number?

Or is it that what is effectively a 14 digit account number, if I make a mistake, the chances of it being a valid number are vanishingly small?
Click to expand...
In your example, the "35" is the checksum. This is calculated by running all the other numbers and letters (A=10, b=11, C=12, X= 33, Y=34, Z=35) through a routine. If you change any one number or letter in the IBAN the result is guaranteed to be different and checksum will be invalid, and so your second IBAN is guaranteed to be rejected. There is a possibility if there are multiple errors (two or more substitutions or transpositions) that the result of the calculation will be the same, but it is very remote possibility, far too remote to be bothered about.
 
Monbretia said:
I would have thought my error could still occur, now mind you small risk and it would be customer error as if I was quoting the IBAN and I put in what used to be the sort code which is incorporated in the IBAN now cos there are several of them in my head memorised then if the UB system was still in place I could hit a valid account in another branch, no?

As in example above when I read IBANs in my head I split the 93-10-63 as I remember them when they were sort codes so what if I put in 93-62-19 with my correct account number is there a chance that will hit a valid account in AIB Tralee or is there only one usage of an account number anywhere in the country?
Click to expand...
It could still occur if you continue to calculate/guesstimate IBANs. Which is a good reason not to do so, and request the actual IBAN from the payee instead of using an IBAN calculator to calculate it, potentially with the wrong data.

At least one Irish bank is still using some forms showing the NSC (sort code) and account number, so you aren't alone. But sort code and account number are now history as far as payments are concerned and relying on them isn't wise.
 
You must log in or register to reply here.
Back
Top