Tag Archive for: Transaction verification

A transfer is the point where a compromised account becomes a loss. Login controls decide who is at the keyboard. Transaction controls decide whether this particular payment should leave the account, and to whom. A bank that answers only the first question leaves the second one open.

For how the login factors compare, see our post on types of MFA used in online banking. The controls below pick up where that one stops.

Transaction verification decides each payment on its own

Transaction verification looks at one payment at a time and decides whether to allow it, challenge it, or hold it. The FFIEC’s 2021 guidance asks institutions to base their authentication on a risk assessment and to use layered security, so the decision depends on the combination of signals rather than on any single one.

Consider a payment of an amount you have never sent, to a payee you added an hour ago, from a device the bank has not seen before. Each signal alone might be explainable. Together they may justify a hold. The risk this control addresses is a valid session used to move money the owner did not intend to move. The bank can reduce that risk by recording the reasons for each decision, so it can explain a hold later. OmniDefend’s customer identity offering lists transaction verification among its capabilities. For the same logic applied at sign-in, see our post on why does my login suddenly require MFA.

Binding each approval to one amount and one payee

Under EU and UK strong customer authentication rules, the approval code must be specific to the payment’s amount and payee. Any change to either one invalidates the code. Suppose you approve a payment of £200 to one payee. A code generated for that payment cannot release £2,000 to a different account. The rules also require that the payer is made aware of the amount and payee before approving, which addresses payments altered after the owner has approved them.

This is the step where transaction verification and the approval factor have to agree. If the approval is not bound to the payment, a good risk score still leaves room for a substituted payment.

Checking the payee’s name before the first payment

In the UK, Confirmation of Payee checks the name entered for a new payee against the name on the receiving account. The Payment Systems Regulator’s Specific Direction 10 required the largest UK banks to introduce it. Take a customer who types a payee name and sees the app report that the name does not match the account. They stop and check the details before sending. The check is aimed at authorised push payment scams, in which a customer is persuaded to pay an account controlled by a fraudster, and at misdirected payments, according to Electronic Payments International.

The limit is scope. The check applies in the UK, and other markets have their own rules, so the same protection does not apply everywhere.

Secure e-commerce transactions at checkout

Online card and account payments are made without the cardholder being physically present, so the bank has less to go on. OmniDefend lists secure e-commerce transactions as part of its secure online experience offering. In practice, that means the same risk decision applies at checkout. A shopper buying from a site they have never used may see the payment approved without a prompt when it looks ordinary, and a confirmation step when it does not.

In general practice, merchants and banks decide together how much friction a checkout can carry. A step that is too heavy loses sales, and a step that is too light lets fraud through. Measuring both outcomes is what shows where the balance sits.

Limiting guesses and idle payment sessions

The EU and UK rules cap consecutive failed authentication attempts at five. After the cap is reached, the action is blocked temporarily or permanently, and a permanently blocked payer must have a secure procedure to regain use of the payment instrument. The same rules set a maximum of five minutes without activity for online access to a payment account. After that, the session must be authenticated again.

Picture someone trying several wrong codes on an account. After the fifth failure, the bank can block further attempts, as the rules allow. These controls address automated guessing of approval codes and a session left open on a shared device. Our post on how hackers bypass 2FA describes reverse proxy attacks that take over a session after login, which is why the inactivity limit matters.

Large-scale identification behind every decision

Each payment decision draws on an identity record: who the customer is, which devices they use, and which payees they have verified. OmniDefend lists large-scale identification and user management APIs among its customer identity capabilities. A customer who changes phones and adds a new payee should have a record that connects the new device and the payee to the same person, rather than leaving them as unconnected events.

The limit is data quality. Identity records only help if they are kept accurate, and duplicate or stale records weaken every decision that depends on them.

What a bank still has to do itself

No transaction control replaces the bank’s own systems. The table separates what each control is responsible for, so no reader assumes a capability covers more than it does.

Account changes the owner should hear about

NIST SP 800-63B-4 expects subscribers to be notified of account events, such as a new authenticator being bound or a recovery being started, so the real owner can spot a takeover, according to a secondary summary by MojoAuth. Suppose you receive a message that a new device was added to your banking app, and you did not add one. The right response is to contact the bank through a number you already know. Notifications only help if they reach the owner, and if the owner has a route to report the change and freeze the account. Our post on tips to improve your customer identity verification process covers how banks tighten the steps that change an account.

Pick the payment your team would least want to fail

Start with the payment type your customers send most often, and check each row of the table against the controls you run today. The row with no owner, or with an owner that cannot cover the case, is the one to address first.

OmniDefend’s 30-day free trial comes with setup handled by our sales team, so the check runs on your own payment flows. If you want to see the capabilities first, request a demo. Start with the 30-day free trial and test one payment type end to end.

Frequently asked questions

Why did my bank hold a payment I started myself?

Transaction verification decides per payment. A payment that is unusual for your account or device can be held for an extra check, and the check confirms that you are the one sending it.

Why does a code stop working when I change the amount?

Under EU and UK rules, the approval code must be specific to the amount and payee. Changing either one invalidates it.

Does the name check protect payments outside the UK?

No. Confirmation of Payee is a UK requirement. Other markets have their own rules, and the checks differ.

Why was I logged out in the middle of a payment?

The EU and UK rules set a maximum of five minutes without activity for online access to a payment account. After that, the session must be authenticated again.

What should I do about an alert for a change I did not make?

Contact your bank through a number you already know, not through a link in the message, and ask them to freeze the account while you investigate.

Resources

• Commission Delegated Regulation (EU) 2018/389, Chapter II (approval code binding, attempt cap, inactivity limit, secure procedure)
• FFIEC Authentication and Access to Financial Institution Services and Systems (2021), via FDIC FIL-55-2021
• Payment Systems Regulator, Specific Direction 10 requiring the introduction of confirmation of payee
• Electronic Payments International, Confirmation of Payee UK
• NIST SP 800-63B-4 account event notification, secondary summary (MojoAuth)
• OmniDefend, How hackers bypass 2FA
• OmniDefend, product listing for customer identity and secure online experience capabilities