- PUSH: - SCT Standard - SCT Instant
- PULL: - SDD Core - SDD B2B
As a bank, you are not forced to support all of them; also, it depends on the local consumer behaviour: in some countries, pull mechanisms are not that widely accepted
DISCLAIMER: Lead Payment Engineer at an European Challenger Bank, i'm implementing that stuff in the backend, i'm mainly talking to our central bank.
Yes, the accounts in my bank (in Finland) default to SEPA Direct Debit off.
For recurring utility payments etc. we instead use Finvoice e-invoicing (https://www.finanssiala.fi/en/topics/finvoice-standard/). The customer enables e-invoices on a per-issuer basis directly from their bank web interface, with an option for auto-pay and payment limits. The payments are processed as regular SEPA payments. The e-invoice goes directly to customer's bank, replacing paper/e-mail invoices.
For paying one-time online purchases the user is redirected to their bank to authorize a one-time SEPA transfer (other non-SEPA payment methods like cards and MobilePay are common, too).
But explaining anything outside of the typically Dutch circumstances is an unfortunate part of life for the not typically Dutch in the Netherlands. Its a deeply cultural thing, this extreme hang towards conformation to a defacto 'normal'.
FYI: millions of Dutch have these kinds of problems. Look up the working poor, its a big group there. IMHO all native Dutch should be forced a few weeks internship with a budget council service, there are so many incorrect preconceptions about poverty. Including who it hits, which definitely includes people who thought they could never possibly be hit, did their finances right, etc.
How your bank presents (or doesn't present) a new SEPA mandate to you for approval is up to them. I'd guess that at least some of them never show you anything, and assume that you will notice and revoke the payment if it was unexpected or fraudulent.
Yes, but how well defined, or how loose, is that "authorization"?
Unfortunately, that depends on the implementation of security the bank adopted. I assume you are mentioning a detail in the PSD2 directive. The banks, especially after national legislation following the directive, may adapt but not overlap it.
Take as an example the rule in the directive, that NFC based payments should require PIN based confirmation every five transactions: not all banks implemented this.
There is also dynamic linking (ie you are shown the amount but also a unique code that the payment requestor also showed you) so you are confident it is the same transaction.
Phone and the gym are the only services that I do not pay by card, but not even by my choosing. Netflix gave me no option. Utilities are bulk included with the rent (transfer) so yeah, just those two.
Oh and I know the card number and codes by heart in case I need to buy anything. Verification is done by SMS.
You have to demand it. (Some of them will propose their solution.)
> if it just culturally never gained traction.
Very few people have read the PSD2 directive. (This friend of mine met a bank consultant who mixed it with a gaming console.)
As a European that moved between countries, I was very surprised when I learned that SEPA allows a "pull" mechanism even exists. I lived 30 years in Latvia without knowing this is a feature in SEPA because every single payment is a "push" mechanism. I'm not sure if banks can turn this feature off, or if it just culturally never gained traction.
On the other hand, payments via banks are fairly widespread C2B, because every bank offers a (custom and horrible) API that merchants can implement. So users can authenticate directly with their bank as if it were PayPal, and authorize a SEPA payment to the merchant's bank account.
In fact, services that care about user identity, will often use these bank APIs to perform authentication with a high degree of confidence about the received user information.
Then I moved to France, and every bank interaction is "pull" based. While friction in Latvia came from authenticating before initiating the "push", in France the friction comes from agreeing to direct debiting, and signing various authorization slips. Sometimes electronically, but sometimes you have to send them by mail before you can start paying for a long-running service by bank (this makes it very undesirable for one-off purchases. In fact it is so cumbersome, that I prefer to pay for many services by credit card every month)
> I doubt the claims of very high fraud rate.
If I provide my account number to a service provider, they can debit it without me explicitly authorizing them (I have to sign an authorization usually, but there's nothing "technically" blocking the counterparty). I suppose that could lead to high fraud rates.