Electronic Financial Transactions Act

For a long time money changed hands at a bank counter. When something went wrong there, it was obvious who answered for it, and banks carried capital requirements and supervision precisely so they could. Internet banking and card payments broke that arrangement. Companies that were not banks started routing payments, holding money collected in advance the way a gift certificate does, and settling funds on behalf of sellers — with none of those requirements attached to them.

The gap showed up whenever something failed. An account gets taken over and money drains out: the user asks the bank, the bank points at the company that routed the payment, and that company answers that the user handled their own password carelessly. Nowhere was it written which of the three pays, so these cases ended up in court and similar incidents produced different rulings. And when a company holding prepaid balances shut down, the balances simply disappeared.

The Electronic Financial Transactions Act was written to close that gap. It nails down three things: register and meet the requirements before doing this kind of business, compensate the user first when an incident occurs, and keep the records and security controls that make an incident reconstructable. The burden that used to sit on users — proving how the money left — flipped direction here.

The statute attaches to a company in three layers: the conditions for opening the door, the liability when something goes wrong, and the state the business has to maintain day to day.

1. Registration and licensing — routing payments or holding money in advance as a business requires registering with the financial regulator first. The category depends on what the company does. Processing card payments on a merchant's behalf is payment gateway business; issuing points or cash balances that users top up and spend later is prepaid payment instrument business; holding transaction funds in the middle and releasing them after delivery is escrow business. Each category carries its own capital, staffing and security requirements.
2. Liability for incidents — when money leaves a user's account through hacking or forged credentials, the operator compensates first. The user does not have to prove the operator was at fault; the operator has to prove the user acted with intent or gross negligence in order to be released. That direction is the heaviest part of the statute.
3. Safety and records — transaction records have to be retained for a set period, and controls such as access logging and anomalous-transaction detection have to be in place. Without the ability to reconstruct what happened, there is no way to allocate responsibility at all.

Most small companies never do the first layer themselves. They contract with an already-registered payment gateway, hand payment processing over, and keep card numbers off their own servers. That is why a checkout flow hands off to the provider's screen and comes back. What transfers, though, is payment processing and nothing else. Build a structure that takes money in advance and that part lands squarely back on the company.

Three moments make this statute concrete for the people building the product.

1. Adding payments for the first time — the decision is how much card data to hold. With a gateway in the flow, the card number is entered on their screen and only a success flag and an identifier come back. Changing that design to store card numbers directly raises what has to be in place by a full step.
2. Building points or credits that users top up — taking money before it's spent can qualify as a prepaid payment instrument. Topped-up balances cannot be mixed with the company's operating funds, and how leftover balances are returned has to appear in the terms of service. This is the feature most often underestimated in a planning meeting.
3. Splitting money across sellers — collecting from customers into the company's own account and paying sellers later counts as holding transaction funds. Any marketplace passes through this.

It looks adjacent to consumer protection rules, but the two examine different things. Those rules look at whether a purchase can be undone; this statute looks at whether the channel the money travels through is safe.

"If we go with a top-up model, we need to look at registering as an electronic financial business."

A design where users buy credit in advance may fall into a registered category.

"We never receive the card number. It goes out to the gateway's window and comes back."

Not storing payment data means not carrying the obligations that come with it.

"Collecting settlement into our account and distributing it later makes that escrow business."

Holding money in the middle is its own registrable activity.

The statute rewrote an entire meeting at Pagedeck when prepaid credits for enterprise customers came up. The first proposal was simple: a large customer deposits a year's worth of spend up front and draws it down, which Mia read as a two-screen feature.

What Grace brought back from counsel was different. Because the money arrives before it is spent, the balances have to be held separately from company funds, the conditions for returning unused amounts have to be spelled out in the terms, and registration may be required depending on scale. The team changed direction: the annual amount goes into the contract and gets invoiced monthly. The customer sees roughly the same thing, but no money arrives in advance, so the statute never attaches directly.

The most common move is assuming a gateway contract ends the conversation. No card numbers, therefore no exposure — and for payments alone that reading holds. But one thing transferred, not all of them. Add points that users top up, or start settling sellers directly, and those pieces come back to the company. That is why it has to be revisited each time a feature lands. Review it once while adding checkout and leave it there, and two years later three or four accumulated features arrive as one problem.

The other frequent assumption is that topped-up points are the company's to expire at will. They only work inside the product, so setting a validity period and clearing them feels ordinary. In practice users paid money for them, which makes the balance closer to a debt owed back than to revenue. Constraints apply to how leftover amounts get handled, and obligations follow that anticipate the company shutting down. Set expiry terms unilaterally, and a dispute can void the clause entirely.