The one-sentence version
Good product design usually pursues "one less step is one better step." However, for operations like transfers and authorizations where errors are irreversible, appropriate "friction" is actually a form of protection: a countdown timer, manually typing a few digits of an address, or a prompt asking, "Did someone ask you to transfer this money?" Risk control scoring determines where to add friction and how much to add: low-risk operations proceed smoothly, while high-risk operations face layers of checkpoints. The goal is not to block everyone, but to interrupt "autopilot" clicking to give the user a chance to stop and think.
This article has three layers:
- Layer 1: The Intuition: Speed bumps
- Layer 2: Real-World Use: Bank anti-fraud questions, UK payee verification, and exchange risk control
- Layer 3: Rules engines, scoring and tiered response, and which friction is actually effective
Layer 1: The Intuition
1.1 Speed bumps
Speed bumps are installed on residential roads. They cause only a slight bump for law-abiding drivers, but they force speeding vehicles to slow down.
Friction in a transfer interface is like a speed bump:
| Friction | What it interrupts |
|---|---|
| A countdown timer before the "Confirm" button becomes active | The habit of clicking "Confirm" without thinking |
| Manually typing the last few digits of a recipient address | The habit of only glancing at the start and end (see "Address Poisoning") |
| "Did someone ask you to transfer this money over the phone?" | The sense of urgency created by scammers |
| Re-authenticating with a fingerprint | Session hijacking (see "Passkeys and Anti-phishing") |
1.2 Why you cannot add it to every operation
If every transfer required a countdown, address entry, and answering questions, users would quickly become numb, completing these steps mechanically like dismissing pop-up ads; the speed bumps would lose their effectiveness. Some users might even switch to a tool that isn't this cumbersome.
Therefore, friction must be scarce: it should only appear when the risk is high so that users will take it seriously.
Layer 2: Real-World Use
- Bank Anti-Fraud Questions: Banks in many countries trigger pop-up questions during large transfers or transfers to new recipients: "Has someone told you this account is unsafe and asked you to transfer to a 'safe account'?" "Has someone asked you to hide the reason for this transfer from the bank?" These questions directly target the most common scam scripts.
- UK Confirmation of Payee (since 2020): Before a transfer, banks check if the recipient's name you entered matches the account details; if they don't match, a clear warning is issued. Starting from October 2024, the UK also requires banks to compensate victims of Authorized Push Payment (APP) fraud under certain conditions, giving banks more incentive to add friction before transfers.
- Exchange Withdrawal Risk Control: A new address, a large amount, a new device, or a recently changed password—each factor increases the risk score, triggering additional verification, delayed arrival, or manual review.
- Credit Card Anti-Fraud: Every transaction is scored in real-time; anomalous transactions are either declined or require SMS confirmation.
Layer 3: Principles and Engineering
3.1 Rules Engine
Each rule is written as "Condition → Score or Level," stored in a configuration file with version numbers, allowing for auditing and rollbacks:
| Rule Category | Example |
|---|---|
| Object | Recipient address is on a scam or sanctions list; first-time recipient; highly similar to historical objects |
| Amount | Proportion of balance is too high; exceeds a certain absolute amount; too much cumulative outflow in a short time |
| Frequency | Abnormal number of transfers within a short period |
| Environment | New device, new IP, session just established, recent security setting changes on the account |
| Asset | Tokens not on the whitelist; suspected counterfeit coins |
| Operation Type | Unlimited authorization (see "Unlimited Authorization"), calling unknown contracts |
Every time a rule is triggered, it must be logged individually: what was triggered, why, and what the data was at that time. This facilitates user understanding as well as post-event review and rule tuning.
3.2 Tiered Response
| Level | Response |
|---|---|
| Low | Normal confirmation page |
| Medium | Prominent warning + Strong authentication |
| High | Strong authentication + Countdown + Manual address entry + Notification |
| Refuse | Disallow initiation on this interface and state the reason |
Key design points:
- Multiple medium-risk factors can escalate to high risk, such as "new device" + "first-time recipient" + "large amount";
- Explain the reason for the trigger in plain language, for example, "This is your first time transferring to this address," rather than "Risk score 72";
- For operations that "increase security," such as revoking authorization or freezing an account, friction should be minimal, otherwise users will find even self-rescue too cumbersome.
3.3 Which friction is actually effective
| Effective | Ineffective |
|---|---|
| Requiring active input of information (digits of an address, amount) | Only requiring a checkbox for "I have read the risk warning" |
| Specific questions targeting specific scam scripts | Vague "Please stay safe" warnings |
| A countdown combined with a prominent risk explanation | A simple countdown (users will just stare at the phone until it finishes) |
| Risk appearing only on a few operations | Popping up every single time |
| Providing an alternative path: transfer a small amount first for testing | Only saying "not recommended" |
3.4 Honestly stating capability boundaries
If a user's wallet is a standard address (EOA), the user can completely bypass your interface and transfer directly within the wallet software. In this case, risk control can only deter, not prevent. The interface should state this truthfully rather than giving the user the illusion that "this place is very safe." Truly mandatory risk control requires moving the rules on-chain (see "EOA vs. Smart Contract Wallets").
3.5 Thresholds are a secret
Rule categories can be made public (which can actually be educational), but specific thresholds should not be public. If an attacker knows that "exceeding X% of the balance triggers verification," they will keep every transaction below X% and transfer the funds in multiple increments.
Summary
| Layer | Key points |
|---|---|
| Intuition | Friction is a speed bump: a bump for normal users, a brake for impulsive actions and scams |
| Principle | Friction must be scarce and appear according to risk levels |
| Effective Practice | Active input, specific questions, providing alternative paths |
| Boundary | On an EOA, you can only deter; keep thresholds secret |