Surge pricing and the model no one explains
Chuxing is a ride-hailing platform with 40 million riders in 120 Chinese cities. Fares are quoted by a model that uses distance, time of day, the rider's handset model, remaining battery level, historical tipping and a 'member score'; the same score also decides queue priority for cars during rain. No human reviews individual quotes. A rider booked an identical route twice from an iPhone 15 and a three-year-old Android handset and found a 23% price difference. She then asked the platform for (1) an explanation of how her quote was produced, (2) a copy of the profile data held about her, and (3) a switch to stop the marketing push notifications she receives four to six times a day. The app routes all such requests to a chatbot that replies 'please refer to the Privacy Policy' and offers no human escalation. The privacy policy runs to 41 pages and mentions 'algorithmic optimisation' once.
1. Is the fare engine 'automated decision-making' under the law, and what obligations attach to it?
Read the worked answer
Yes. Under Article 24, automated decision-making means decisions produced by computer programs using personal information, without human involvement, in the course of information push, commercial marketing, or decisions that significantly affect the individual's rights and interests. Fare pricing and priority dispatch are decisions with direct economic effect on the rider, produced with no human in the loop.
Obligations under Article 24:
- Transparency and fairness. The handler must ensure the decision is transparent and the results are fair and equitable, and may not apply unreasonable differential treatment in transaction conditions - including price - based on personal characteristics. A 23% spread attributable to handset model is precisely the practice the article targets.
- Explanation and refusal. Where a decision significantly affects rights and interests, the individual is entitled to demand an explanation and to refuse a decision made solely by automated means. In practice, 'explanation' means the material logic and the specific factors driving her quote, not disclosure of source code; a regulator will test whether the explanation is concrete enough to be meaningful.
- A human review route. The right to refuse presupposes a human alternative, which the chatbot loop removes.
Before that, a governance failure: Article 55(3) requires a personal information protection impact assessment before deploying automated decision-making, and Article 56 requires the report and processing record to be kept for at least three years. Neither is evidenced here.
2. How should the platform respond to each of the rider's three requests?
Read the worked answer
Request 1 - explanation of the quote (Article 24). Provide the specific factors that produced her fare: base distance and time components, the surge multiplier applied, the member-score band, and confirmation of whether handset attributes were used. Where handset model materially raises a price, the platform must either stop using it or show an objective, non-discriminatory justification. 'Algorithmic optimisation' in a 41-page policy is not an explanation.
Request 2 - copy of the profile (Article 45). Provide access to, and a copy of, the personal information held about her, including the derived member score, profile tags, tipping history and device attributes. Derived or inferred data is still her personal information. Article 45 also supports transfer to another designated handler where the conditions for portability are met.
Request 3 - stop the marketing push (Article 24(2)). Where information is pushed or published to individuals through automated decision-making, the handler must simultaneously provide the option not to target the individual's personal characteristics, or a convenient method of refusal. Refusal must be available and must not be unreasonably conditioned - for example, not by demanding she close her account. Article 50 additionally requires a convenient channel for rights requests; routing everything to a bot with no escalation path fails that requirement, and Article 50 entitles her to complain to the regulator.
Also: Article 47 deletion and Article 46 correction rights should be offered, and all correspondence retained as evidence of how the request was handled.
3. The company argues that the model simply reflects market demand and that the price difference was a coincidence. How should a reviewer test that claim?
Read the worked answer
A defence of 'market demand' must be evidenced, not asserted. A reviewer should require:
- Feature documentation. A written list of every input to the pricing and dispatch model, with the business justification and the Article 6 minimum-necessity test applied to each. Device model and battery level are the weak points: neither is a demand signal.
- A/B evidence. Results of a controlled test showing that removing handset attributes does not change revenue materially - or, if it does, that the effect is explained by a legitimate cost or risk factor rather than willingness to pay.
- Dispatch equity analysis. The member score controls queue priority during rain. If the score correlates with spending history, the platform is selling queue position based on personal characteristics, which sits awkwardly with Article 24's fairness requirement.
- The impact assessment. Article 55(3) requires one before deployment. If none exists, the claim cannot be tested retrospectively, which is itself the finding.
- Records. Article 56 requires the impact assessment report and processing record to be kept for at least three years, so a missing record is an independent breach.
Conclusion for the reviewer: a coincidence claim is not a legal argument. The burden sits with the handler to show that the personal characteristics used are necessary, proportionate and applied without unreasonable differential treatment; absent documentation, the platform should suspend the device-attribute feature pending a rebuilt assessment.