Pricing Strategy

Dynamic Pricing Fairness Audits: A Practitioner Method for Pre-Launch and Continuous Review

Dynamic pricing systems can drift into discrimination without anyone in the team intending it. The audit method is borrowed from credit modeling, adapted for pricing CI/CD, and made boring enough to run every release.

Share

TL;DR: A dynamic pricing system can produce disparate outcomes across protected and proxy-protected groups even when the team building it has no intent to discriminate. The right operational response is a fairness audit run inside the pricing CI/CD pipeline rather than a one-off review by an outside firm. This essay walks through the legal landscape (Robinson-Patman, the FTC's surveillance pricing study, the EU AI Act, the UCPD, and California's surveillance-pricing initiative), the technical audit methods (disparate impact, counterfactual fairness, Shapley attribution), and an operational integration that treats fairness checks as deploy-blocking tests alongside revenue regressions.

A note on sources and examples. The Uber, Amazon, and major retailer cases referenced here are public. The audit method described draws on advisory engagements with two e-commerce operators (one apparel marketplace, one travel platform), and the quantitative figures attributed to the audits come from anonymized partner-engagement data rather than from the named companies. The legal interpretations are the practitioner's reading; this is not legal advice.


Why the Audit Is Necessary

The simplest description of a dynamic pricing system is a function that takes a context (a product, a session, a customer, a time, a competitive snapshot) and returns a price. Modern implementations of this function are statistical: they learn from historical transactions which contexts produced sales at which prices, and they extrapolate. When the extrapolation is faithful to the training data, the system reproduces the patterns that already existed. Some of those patterns are commercially desirable. Some are illegal.

The unintended discrimination problem in pricing is the same as the unintended discrimination problem in credit and hiring. A pricing function trained on transaction history does not need to receive race, gender, or age as inputs to produce outcomes correlated with race, gender, or age. The features the model does receive (browser, IP geography, device, traffic source, time of day, payment method, browse history) are correlated with protected characteristics in ways that the model exploits because they predict price acceptance. The exploitation is not anyone's intent. It is what happens when the loss function rewards revenue and the training data reflects the structure of the society the customers live in.

The legal literature has been clear on the principle for at least a decade. The applied literature on what to do about it operationally is younger. Solon Barocas, Moritz Hardt, and Arvind Narayanan (2019, fairmlbook.org; MIT Press 2023) collected the technical foundations in Fairness and Machine Learning. Nathan Kallus and Angela Zhou (2021, ACM FAccT) wrote the first widely cited paper on fairness specifically in personalized pricing, arguing that the dominant ML-fairness criteria (demographic parity, equalized odds) do not translate cleanly to pricing and that pricing requires its own framework. The empirical record on actual discrimination in deployed pricing systems is uneven; the FTC's 2024 surveillance-pricing study (FTC, January 2025) is the most recent regulator-side documentation of the scope.

This essay is the practitioner method. It is opinionated about three things. First, fairness audits work better when they are run continuously, inside the pricing release pipeline, than when they are one-off projects. Second, the right technical primitives are simpler than the academic literature might suggest: disparate impact at the segment level, a counterfactual-fairness check on the model, and Shapley attribution on the features that drive disparity. Third, the audit needs to surface decisions to humans, because most fairness questions in pricing are about which trade-offs the business is willing to accept, not about which output the model "should" produce.


The legal environment around dynamic pricing in early 2026 is a layered patchwork. The teams we have worked with treat the legal posture as a constraint set rather than as a single rule, because no single rule applies cleanly to all the markets they operate in.

United States: Robinson-Patman, the FTC, and the state landscape. The Robinson-Patman Act of 1936 (FTC overview) prohibits price discrimination in the sale of commodities of like grade and quality where the effect may be to substantially lessen competition. The Act was largely dormant from the 1980s through the early 2020s. The FTC under chair Lina Khan signaled a revival in 2022 to 2024, culminating in the Southern Glazer's complaint in December 2024, the first government RPA case in over twenty years (Paul Weiss memo). The Act's direct application to consumer dynamic pricing is debated: most consumer transactions involve the kind of differentiated goods that the Act treats less strictly than commodities. The Act applies more cleanly to wholesale pricing, B2B pricing, and platform-to-merchant pricing.

The more active US-side framework for consumer-facing dynamic pricing is the FTC's Section 5 authority on unfair or deceptive practices, plus the new state-level surveillance-pricing initiatives. The FTC's July 2024 6(b) study sent orders to eight intermediaries (Mastercard, Revionics, Bloomreach, JPMorgan Chase, Task Software, PROS, Accenture, and McKinsey) seeking information on personalized pricing infrastructure (FTC release, July 2024). California Attorney General Rob Bonta launched a surveillance-pricing sweep in January 2026, focused on CCPA compliance for businesses using personal information to set targeted prices (California AG release). New York's algorithmic pricing disclosure law came into force in 2025, requiring businesses to disclose when an algorithm uses personal data to set price.

European Union: AI Act, UCPD, and the Digital Fairness Act. The EU AI Act (Regulation (EU) 2024/1689) classifies certain pricing systems as high-risk, particularly those used for credit scoring and insurance pricing. The high-risk requirements become mandatory on August 2, 2026, with fines up to €35 million or 7% of global revenue for the most serious violations. For most retail e-commerce pricing, the AI Act's direct applicability is limited but the UCPD (Unfair Commercial Practices Directive 2005/29/EC) is more directly relevant. The UCPD prohibits deceptive and aggressive commercial practices, which the European Commission has interpreted to include certain forms of undisclosed personalized pricing. The forthcoming Digital Fairness Act, signaled in the Commission's 2024 to 2025 work program, is expected to extend the UCPD specifically to algorithmic price personalization.

United Kingdom: ARP, ASA, and CMA digital markets work. The UK retained the Unfair Commercial Practices framework post-Brexit and added the Digital Markets, Competition and Consumers Act 2024, which the CMA is using to scrutinize algorithmic pricing on designated digital platforms. The Advertising Standards Authority (ASA) enforces the rule against misleading price claims, including drip pricing and personalized "from" prices.

Legal Frameworks Touching Dynamic Pricing, by Jurisdiction (Early 2026)

JurisdictionFrameworkTrigger / ScopeCompliance Implication for Dynamic Pricing
US FederalRobinson-Patman Act (1936)Like-grade commodities; competition effectPrimarily wholesale; consumer cases rare but rising
US FederalFTC Section 5 (unfair/deceptive)Misleading or harmful commercial practicesActive 2024-2026 surveillance pricing inquiry
CaliforniaCCPA + surveillance pricing sweep (Jan 2026)Use of personal data to set priceDisclosure and purpose-limitation pressure
New YorkAlgorithmic Pricing Disclosure Law (2025)Algorithm + personal data → priceDisclosure obligation at point of sale
EUAI Act (Reg 2024/1689), high-risk obligations from Aug 2026AI systems in credit/insurance pricingRisk management, logging, human oversight
EUUCPD 2005/29/ECMisleading/aggressive practicesUndisclosed personalization can be UCPD breach
EU (forthcoming)Digital Fairness ActAlgorithmic price personalizationExpected stronger disclosure + opt-out rights
UKDigital Markets Competition and Consumers Act 2024Designated digital platformsCMA scrutiny on platform pricing algorithms
UKAdvertising Standards Authority (ASA)Misleading price advertisingDrip pricing, deceptive From-prices

A team operating dynamic pricing in even three of these jurisdictions faces a compliance surface that no single legal posture covers. The pragmatic operational stance, in our advisory observations, is to design the pricing system to a stricter internal standard than any one regulator currently requires, on the bet that the regulatory direction across all of them is converging on more disclosure, more documented oversight, and more constraint on the use of personal data.


What "Fair" Means in Pricing (Adjusting the Imported Definitions)

The ML-fairness literature provides several technical definitions of fairness. Most were developed for classification problems (loan approval, hiring screen, recidivism prediction) and do not transfer cleanly to pricing. The Kallus and Zhou (2021) paper made this point explicitly. Below is a practitioner's adaptation.

Demographic parity in classification says the predicted positive rate should be equal across protected groups. The pricing analog is that the average price paid should be equal across protected groups. This is a strong claim; it precludes any price variance that correlates with the protected attribute, even when the variance is driven by causally unrelated factors (geography of warehouses, shipping cost, currency exchange). Demographic parity is the right target only in jurisdictions and product categories where any price variation correlated with the protected attribute is unacceptable, which is unusual.

Equalized odds in classification says the true positive rate and false positive rate should be equal across groups. The pricing analog is harder to define because pricing does not have a clean "positive" outcome. One useful adaptation is to equalize the conversion rate across groups at any given price, which is approximately the condition that the price elasticity function should be the same across groups. This is a weaker claim than demographic parity and a more defensible operational target.

Counterfactual fairness (Kusner, Loftus, Russell, Silva, 2017, NIPS) asks whether the model's output for a specific customer would change if the customer's protected attribute were different, holding all the causally-downstream-of-protected features constant. For pricing, this asks: if this customer were a different gender (or race, or age) but otherwise identically situated, would the system show a different price? Counterfactual fairness requires a causal model of how the protected attribute relates to the features the model uses, which is usually contested and rarely fully specified. But the question it asks is the one most relevant to dynamic pricing: does the system treat this individual differently because of who they are?

Equality of opportunity (Hardt, Price, Srebro, 2016, NIPS) is equalized odds restricted to the positive class. For pricing, this would mean that, conditional on the customer being a high-willingness-to-pay buyer, the prices offered should be equally distributed across protected groups. This is too narrow for most pricing applications.

The choice of fairness criterion is a business and legal decision, not a technical one. Demographic parity is the strongest claim, the easiest to communicate, and the hardest to implement without leaving revenue on the table. Equalized odds and counterfactual fairness are weaker, more defensible operationally, and more sensitive to the precise causal model the team is willing to commit to.


The Audit Pipeline: Six Stages

The audit method we run in advisory engagements has six stages. The order matters: skipping a stage makes the later stages either uninformative or wrong.

The six-stage fairness audit pipeline for a dynamic pricing model

Loading diagram...

Stage 1: Define protected and proxy attributes. The protected attributes are the demographic categories the team commits to monitoring: typically race, gender, age, disability, and pregnancy status. The proxy attributes are features the model uses that are known to correlate strongly with the protected attributes. The list of proxies depends on the jurisdiction and the model's feature set, but commonly includes geographic ZIP/postcode (a strong proxy for race in many US markets), device type and browser (correlated with age and income), IP geography (correlated with country of origin and immigration status), and first name or last name strings (correlated with race and national origin).

In practice the team rarely has access to the protected attributes themselves at the individual level. The audit instead uses statistical estimation: Bayesian Improved Surname Geocoding (BISG) for race in US markets (Elliott et al., 2009, Health Services and Outcomes Research Methodology), or census-tract-level demographics matched to ZIP, are the standard tools. Both produce probabilistic estimates of the protected attribute that are good enough for cohort-level audit purposes but not good enough for individual-level claims.

Stage 2: Construct test cohorts. Build matched cohorts that are similar on the non-protected business-relevant features (product category, basket size, prior purchase history, channel of arrival) but differ on the protected or proxy attribute. The match can be done with propensity score matching, coarsened exact matching, or Mahalanobis distance, depending on the data shape. The output is a set of paired or grouped observations where the only meaningful difference is the protected attribute (or the proxy that estimates it).

Stage 3: Measure disparate impact at the segment level. For each pair or matched group, compare the prices offered, the prices accepted, and the conversion rate. The classic disparate-impact metric is the four-fifths rule, originating in US employment discrimination case law and adopted as a screening heuristic in the EEOC's Uniform Guidelines (1978): if the selection rate for any protected group is less than four-fifths of the rate for the most-favored group, the practice is treated as evidence of adverse impact. In pricing, the four-fifths rule can be adapted: if the average price paid by the protected group differs from the reference group's price by more than 20% (or the conversion rate differs by more than 20%), the practice merits investigation. The 20% threshold is not legally definitive; it is the screening signal.

Stage 4: Counterfactual probe per individual. For a sample of individual customers, ask the model to produce a price for the customer's actual feature vector and for a counterfactual vector where the protected attribute is changed but the rest is held constant. The price delta is the per-individual counterfactual disparity. The aggregate distribution of these deltas across the sample is the counterfactual-fairness diagnostic.

Stage 5: Shapley attribution on disparity drivers. When the audit finds disparity, the next question is which features are driving it. Shapley value-based feature attribution (Lundberg and Lee, 2017, NIPS) is the most well-defined attribution method for this purpose. The Shapley value for each feature is the average marginal contribution of that feature to the model's output across all possible feature orderings. Applied to the disparity (the difference in average price between protected and reference groups), the Shapley decomposition tells the team which features explain the most of the disparity.

Stage 6: Decide and document. The audit produces a disparity measurement, a counterfactual diagnostic, and a Shapley decomposition. The decision is whether to accept the disparity, modify the model, or pull a specific feature. The documentation records the decision, the rationale, and the date, in a form that can be reviewed by legal, by a regulator, or by an external auditor.

Audit Output Example: Apparel Marketplace Pricing Model v3.2

MetricReference GroupComparison GroupDisparityFour-Fifths ScreenDecision
Average price offered ($)117.40121.80+3.7%PassAccept
Conversion rate at offered price8.4%6.9%-17.9%BorderlineInvestigate
Average price paid ($)112.10119.20+6.3%PassAccept
Coupon-eligibility rate42%27%-35.7%FailModify model
Free-shipping threshold reach61%44%-27.9%FailInvestigate
Counterfactual price delta (median)0+$2.40Significantn/aModify model

The example output is illustrative, not real. The pattern it shows (small average disparity, larger conversion disparity, large disparity in promotional eligibility) is typical: the pricing model itself may be roughly fair on the headline metric but the promotional and coupon allocations that ride on top of it amplify into much larger disparities. Most of the actual fairness work happens at the promotion layer, not the base-price layer, because that is where the model's training signal is strongest and the disparity has the most room to grow.


Counterfactual Probes in Practice

The counterfactual stage is the most technically delicate. The probe asks: if this customer's protected attribute were different, would the price change? Two implementation choices materially affect the answer.

Choice A: Replace the proxy, replace nothing else. The simplest probe replaces a proxy feature (the ZIP code, the device type, the browser) with a value that swaps the inferred protected attribute and leaves everything else unchanged. The price delta is recorded. This is the cleanest implementation but it underestimates the true counterfactual disparity because it does not capture the chain of features causally downstream of the protected attribute that the model also uses.

Choice B: Use a causal model to update downstream features. A more thorough probe builds a causal directed acyclic graph (DAG) of how the protected attribute relates to the model's features, and updates all the downstream features consistently with the counterfactual change in the protected attribute. This is the Kusner-Loftus-Russell-Silva method. It is more accurate but requires committing to a causal model that is often contested. The team has to choose: which features are caused by gender, which are caused by socioeconomic status that is correlated with gender, which are independent.

In practice we run both probes and compare. If Choice A and Choice B produce similar disparities, the team can be more confident in the result. If they diverge sharply, the team is being told that the disparity is highly sensitive to the causal assumptions, which is itself a finding worth documenting.

Illustrative Counterfactual Price Delta Distribution: Two Probes, One Model

The distribution in the chart shows two probes finding different proportions of customers whose price would change under the counterfactual swap. Probe A (simple proxy swap) finds 23% of customers in a non-trivial range; Probe B (causal DAG update) finds 36%. Whether the team treats this as evidence of a fairness problem depends on the threshold of acceptable disparity, which is a policy decision, not a model output.


Shapley Attribution: Which Features Drive Disparity

When the disparity is non-trivial, the operational question is which features the team should reconsider. Shapley attribution provides the cleanest answer. The Shapley value ϕi\phi_i for feature ii is:

ϕi=SF{i}S!(FS1)!F![f(S{i})f(S)]\phi_i = \sum_{S \subseteq F \setminus \{i\}} \frac{|S|!(|F|-|S|-1)!}{|F|!} \left[ f(S \cup \{i\}) - f(S) \right]

where FF is the set of features, SS is a subset not containing ii, and ff is the model's output. The Shapley value is the average marginal contribution of feature ii across all possible subsets. For pricing, applying Shapley to the disparity itself (the difference in average price between the protected and reference groups) decomposes the disparity into per-feature contributions.

Shapley Attribution of Average Price Disparity: Apparel Model Example

The example attribution shows ZIP code prefix and device type accounting for 59% of the price disparity. The team's options at this point are several. Drop the features (acceptable if the revenue impact is acceptable). Bin the features more coarsely (drop ZIP+4 down to three-digit ZIP, group device types). Apply an in-processing constraint that penalizes the model when it relies on the high-disparity features. Or accept the disparity and document the rationale (for instance, if ZIP is being used legitimately for shipping cost differentiation rather than for willingness-to-pay inference).

A practical refinement: when the model is a tree ensemble or a neural net, the Shapley values are estimated rather than exact, because the exact calculation is exponential in the number of features. The Lundberg-Lee TreeSHAP algorithm produces exact values for tree ensembles in polynomial time. For neural nets, approximations like KernelSHAP or Integrated Gradients are the standard. The interpretation is the same; the precision is different.


Integration Into the Pricing CI/CD Pipeline

The single biggest determinant of whether a fairness audit actually controls outcomes is whether the audit runs as part of the pricing model's release pipeline or as a separate, scheduled exercise. The teams that succeed have moved the audit inside CI/CD. The audit is a deploy-blocking test alongside the revenue-regression test.

The architecture looks roughly like this. A new pricing model candidate is trained on the latest data. It runs through the standard model-quality suite: out-of-sample accuracy, revenue counterfactual against the current production model, latency benchmarks. It then runs through the fairness suite: disparate-impact screen, counterfactual probe, Shapley attribution. If any of the fairness metrics regress beyond a configured threshold versus the production model, the deploy is blocked. The model team can either modify the candidate or escalate to a human review committee that has explicit authority to approve a regression.

Pricing model release pipeline with fairness audit gating

Loading diagram...

The teams we have observed converge on three configuration choices that make this architecture functional.

Configuration 1: The thresholds are written down. Not in the head of one engineer. In a configuration file checked into the same repository as the model code. The thresholds typically include: maximum acceptable disparate-impact ratio for any protected dimension, maximum acceptable counterfactual price delta at the 95th percentile, maximum acceptable Shapley contribution of any single proxy feature to the disparity. The values are reviewed quarterly.

Configuration 2: The human review committee is named, reachable, and has a service-level commitment. The committee usually has at least one legal/compliance representative, one product/business representative, and one model-team representative. It commits to making decisions within 72 hours of a blocked deploy. Without the SLA, the audit becomes a deploy bottleneck and the team will route around it.

Configuration 3: The audit results are versioned and stored. Every model release, whether approved or rejected, leaves an artifact. The artifact includes the audit metrics, the decision, and the rationale. The artifact survives team changes, vendor changes, and re-organizations. It is the document the team produces when a regulator or external auditor asks "how did you arrive at this pricing decision?"

Fairness Suite Configuration Example, Illustrative Apparel Pricing Repository

CheckThresholdAction on BreachOverride Authority
DI ratio (price), protected vs reference≥0.85Block deployCompliance lead
DI ratio (conversion at offered price)≥0.85Block deployCompliance lead
DI ratio (promotion eligibility)≥0.80Block deployCompliance lead
Counterfactual price delta (median)≤$1.00WarnModel lead
Counterfactual price delta (95th pct)≤$5.00Block deployCompliance + model lead
Shapley contribution of any proxy feature≤30% of total disparityWarnModel lead
Maximum BISG-conditional price gap (any metro)≤4%Block deployCompliance lead

The thresholds in the table are illustrative and not portable across product categories. A grocery delivery service operating thin margins on commodity goods will set tighter bounds than a luxury fashion marketplace operating wider margins on differentiated goods. The team's job is to set the bounds, document them, and review them on a schedule, not to look up a default.


Mistakes to Avoid

A short catalog of the mistakes we have observed teams make when standing up a pricing fairness audit for the first time.

Mistake 1: Auditing only the model, not the system around it. The base price the model produces is one of perhaps seven decisions that determine the price the customer eventually pays. The others include the promotion eligibility, the coupon distribution, the free-shipping threshold, the loyalty discount, the bundle composition, the layout choice that determines which prices are visible, and the inventory-driven dynamic markups. Auditing only the base price model misses most of the disparity in the system.

Mistake 2: Confusing disclosure with audit. Some teams interpret the regulatory pressure as a disclosure problem and respond by adding a privacy-policy paragraph that mentions algorithmic pricing. Disclosure is necessary in most jurisdictions and not sufficient anywhere. The audit measures outcomes; the disclosure describes the practice. Both are needed and neither substitutes for the other.

Mistake 3: Hiring a one-off external audit and putting it on the shelf. A point-in-time external audit produces a snapshot that is out of date the next time the model retrains, which is often weekly. The audit only controls outcomes if it runs at the same cadence as the model. External auditors can certify the framework; the framework itself has to be internal.

Mistake 4: Treating fairness as a constraint added at the end. Fairness is most cheaply addressed in the feature engineering and the training-objective design. Trying to fix a discriminatory model by re-weighting outputs after the fact (post-processing) is the most brittle and least defensible technique. In-processing constraints (adding a fairness regularizer to the training loss) and pre-processing techniques (reweighting or transforming the training data) are more robust and easier to document.

Mistake 5: Auditing for fairness in dimensions the team cares about, ignoring the ones it does not. The audit framework should monitor at least the protected dimensions in the jurisdictions the team operates in, plus any dimension where the team has been on the wrong side of a public discussion. In practice, this means race, gender, age, disability, geography (rural/urban), income (estimated via census tract), and any other dimension the team has internal reason to expect disparity in.


Decision Tree: How Strict Should Your Audit Be

The tree skips a question that occasionally matters more than the rest: does the team have the appetite to actually block deploys when the audit fails? A fairness audit framework that produces findings nobody acts on is operationally identical to no audit. The first place to test the team's appetite is to run the audit on the current production model and see what it finds. Most teams discover that the production model has at least one finding they would not have shipped if the audit had existed before the deploy.

The audit only controls outcomes if the audit can block deploys. The audit is a politics document, not a technical document, and the politics decide whether the technique survives.


What We Are Watching For Next

A few open questions that we do not have settled views on.

The aggregation question. Most current audits operate at the segment level (race, gender, age, geography) with each dimension audited independently. The intersectional case (the customer who is at the intersection of multiple protected attributes) is harder to audit because the cells get small and the statistical power degrades. The right method for intersectional auditing in pricing is unsettled. Buolamwini and Gebru's Gender Shades work (2018, FAT/ML) made the case for intersectional audits in computer vision. The transfer to pricing is in progress.

The dynamic-equilibrium question. A pricing model that is audited fair today, deployed, and retrained on the resulting transactions can drift back into unfair territory because the customers who were excluded by the original disparity are now even more under-represented in the new training data. This is the classic feedback loop in deployed ML systems. The right protocol for monitoring drift in fairness metrics is similar to the calibration loop for anomaly detection: periodic re-audit, label-stable test cohorts, and human review of the trajectory.

The disclosure question. New York and several other US states are moving toward mandatory disclosure when an algorithm uses personal data to set a price. The EU's Digital Fairness Act is likely to formalize the same direction. The form of the disclosure (a banner, a click-through, an opt-out, an explanation of which features drove the price) is undecided. The legal and behavioral-economics literatures disagree about whether disclosure changes consumer behavior in any meaningful way. The teams we work with treat disclosure as a near-certainty in the medium term and design their systems to be disclosable without re-architecting later.

Key Takeaways

  1. The audit is not optional. Any dynamic pricing system trained on historical transaction data is statistically likely to produce disparate outcomes along at least one protected or proxy-protected dimension. The right operational stance is to audit by default, not by exception.
  2. Borrow the technical primitives from the credit and hiring fairness literature. Disparate impact (the four-fifths rule), counterfactual fairness (Kusner et al., 2017), and Shapley attribution (Lundberg and Lee, 2017) are the three operational tools. They do not replace each other; they complement each other.
  3. Move the audit inside CI/CD. A one-off external audit produces a snapshot that is out of date as soon as the next model retrains. The audit only controls outcomes if it runs at the same cadence as the model, with deploy-blocking authority and a human review committee with a 72-hour SLA.
  4. Audit the system around the model, not just the model. Promotions, coupons, free-shipping thresholds, and layout choices typically amplify base-price disparities by factors of two to five. Most of the disparity that matters is downstream of the base-price model.
  5. Document the trade-offs explicitly. Fairness in pricing is not free. A real audit will identify revenue-versus-disparity trade-offs that require executive decisions. The decision-and-document step is the part that separates a framework that survives regulatory scrutiny from one that does not.
  6. Watch the legal landscape converge. The FTC, EU AI Act, UCPD, California CCPA, New York algorithmic-pricing disclosure law, and the forthcoming EU Digital Fairness Act are converging on similar directions: more disclosure, more documented oversight, more constraints on personal-data inputs. Design to the stricter standard and you will be ahead of the regulator regardless of which jurisdiction tightens first.

The Conversation

Be the first to weigh in

Join the conversation

Disagree, share a counter-example from your own work, or point at research that changes the picture. Comments are moderated, no account required.

Read Next