You send the request, so you own the authorisation

On 20 August the SFC issued Circular 26EC51 on the growing use of simplified eDDA arrangements for receiving client deposits. The distinction it turns on is small and easy to miss. Under a standard eDDA, your client sets up the direct debit through their own bank. Under a simplified eDDA, your firm does it — as payee, you submit the setup request to your own bank on the strength of the client’s pre-authorisation and the details they typed into your app: bank name, account number, account owner’s name, and the type and number of the identification document used to open that bank account.

Your bank passes the request to the client’s bank. And here is the part that matters: the payer bank may or may not ask the account owner to confirm it. Where it does not, the SFC’s position is that the firm which initiated the request bears primary responsibility for having obtained proper authorisation from the bank account owner. Your bank may separately require you to confirm you have it, and may require you to indemnify it against losses, liabilities and third-party claims arising from the setup or the deposits that follow.

So the two named risks are not abstract. One is impersonation and unauthorised access — somebody who has got into a client’s trading account, with stolen personal and bank details, setting up a debit the real account owner never knew about. The other is the indemnity: a fraudulent or simply erroneous request, and the claim lands on your balance sheet.

• Who’s in scope: licensed corporations, SFC-licensed virtual asset service providers and associated entities that use simplified eDDA to receive client deposits — the circular names internet brokers and virtual asset trading platform operators as the typical users. If your clients fund their accounts only by ordinary bank transfer or standard eDDA, this one is a reading exercise, not a project.

• What to do: two things, in order. First, assess: read the service agreements, terms of business and other contractual documents with your bank, and specifically the terms of any indemnity you have given or are about to give. Identify which payer banks your payee bank can facilitate, and find out which of them require owner confirmation. Judge whether your operational capability — and your financial resources to meet potential claims — match that exposure, and re-run the assessment periodically and whenever the scale or risk profile changes.

  Second, before you process any new setup request, establish two facts. That the request is authorised by the account owner: either satisfy yourself the payer bank has a robust authentication process for confirming that (asking through your own bank, or the payer bank directly), or ask the client for a one-off small-value transfer from that very account and match the account holder’s name against the deposit record your bank gives you. And that the identification information submitted is verified: accept only details identical to your own client records — name, ID document type, ID number — or, where they differ, obtain the identification document purportedly used to open the bank account.

• By when: the circular sets no deadline, which is not the same as no urgency. The trigger is transactional: the checks above apply before processing any new simplified eDDA setup request, and the risk assessment is expected before entering into or continuing with existing arrangements. In practice that means the next request through your app is already in scope.

Where those checks cannot reasonably be satisfied, or your ongoing monitoring throws a red flag, the expectation is to decline the setup and/or withhold the deposit instruction and anything that follows on that account until you have done the follow-up work. The red flags listed are worth pasting straight into your monitoring rules: repeated failed setup requests or deposits; frequent or large eDDA deposits in a short period with no apparent commercial rationale; deposits inconsistent with the client’s financial profile or historical pattern; a new eDDA setup followed by the whitelisting of a new virtual asset wallet address, or the reverse, particularly for an existing client; and deposits converted into virtual assets and withdrawn shortly afterwards.

Two smaller obligations ride along with it. Disclose the eDDA settings — any limits on amount or frequency, any expiry date — get the client’s consent to them, and remind clients to review their registered accounts and watch their own bank statements. And if you cannot mitigate the risk adequately, the circular is blunt about the alternative: use standard eDDA, bank transfers, or another appropriate method instead.