From a data architecture perspective, this breaks one of the fundamental principles "thou shalt not re-use a data field for data that has another meaning".

How on earth do you know (though a human could easily tell) what data is in the field - the name or the name + auth code and know how to treat this accordingly? You would still have to change the back-end coding to not store the one-time auth code, if (and should the Data Protection Act allow) you wish to re-use the card holder name field.

How does a retailler know that the new account, marked as "trusted vendor" is not using a false address if there is no vendor address verification process? In addition, fraudsters are already trying such tricks as pulling their car up onto the driveway of holidaying owners or arriving just as the scheduled van arrives and saying they have "only just got home".

It is this sort of undesign that causes nightmares and sleepless nights for the support team. Especially when it ends up as an "undocumented feature"...

Yes, it may work - as a quick and dirty fix - but I am extremely surprised to see it being recommended as a strategic option.

There is, however, much value in the idea of using a mobile phone for one-time authentication. Even if both the card and phone are stolen, the latter may, nowadays, be registered with MIND and quickly blocked (and is more likely to be missed).