Regulatory Spine — Global

The four questions every regime asks

Regimes differ in detail and converge on four questions. If you can answer these, you can navigate most jurisdictions.

1. Are you allowed to make this decision automatically? Most regimes permit it with conditions. Some grant a right to human review.
2. Can you explain the decision? Nearly every regime requires a reason for an adverse outcome.
3. Can you show it does not discriminate? The legal test varies enormously — from explicit disparate impact doctrine to nothing at all.
4. Where may the data go? Cross-border transfer rules determine which AI APIs you may lawfully call.

The major regimes at a glance

The one that catches people out

The United States has no AI statute for finance, which is frequently misread as meaning there are no rules. The opposite is true.

The Equal Credit Opportunity Act and the Fair Credit Reporting Act predate modern AI and apply to it fully. ECOA requires a specific adverse action reason. Regulators have stated plainly that a model being complex is not an excuse for failing to provide one.

EU AI Act — what actually applies

The Act classifies by risk. For financial services the consequential classification is that creditworthiness evaluation of natural persons is high-risk, as is risk assessment and pricing in life and health insurance.

High-risk obligations include a risk management system, data governance covering training data quality and bias examination, technical documentation, automatic logging, transparency to deployers, human oversight, and accuracy, robustness and cybersecurity.

Note the split of duties: a provider develops the system, a deployer uses it. Most fintechs are deployers, but building your own credit model makes you a provider, with materially heavier obligations.

GDPR Article 22 — the automated decision right

Article 22 gives a data subject the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects. A credit refusal qualifies.

There are exceptions — contractual necessity, explicit consent, authorisation by law — but where you rely on one you must still provide safeguards: the right to obtain human intervention, to express a point of view, and to contest the decision.

Practically this means a credit decisioning system serving EU customers needs a human review path that is real rather than nominal. A reviewer who rubber-stamps at scale does not satisfy the requirement.

US fair lending in practice

Two statutes do most of the work.

ECOA and Regulation B prohibit discrimination on protected characteristics and require a specific, accurate adverse action notice. Generic reasons are not compliant.

FCRA governs consumer report data. If you use a consumer report you inherit obligations including accuracy, dispute handling and adverse action disclosure.

The doctrine that shapes model design most is disparate impact — a facially neutral practice that disproportionately harms a protected group can be unlawful even without intent. That makes proxy variables a live legal risk, not merely an ethical one.

Designing for multiple jurisdictions

Building separately per market is expensive and diverges quickly. The workable pattern is one architecture with jurisdiction as configuration.

# One decision service, jurisdiction-aware policy layer.

decision_request
  -> feature_assembly           # respects per-jurisdiction data permissions
  -> policy_gate(jurisdiction)  # which features are permitted here
  -> model_inference            # same model, jurisdiction-filtered features
  -> reason_generator           # adverse-action reasons in required format
  -> human_review_router        # mandatory in some jurisdictions, optional elsewhere
  -> decision_log               # immutable, includes model version + policy version

# Config, not code:
policy:
  EU:  { high_risk: true,  human_review: on_adverse, prohibited_features: [...] }
  US:  { disparate_impact_test: required, adverse_action_codes: ECOA }
  IN:  { data_residency: local, kyc_process: RBI_V_CIP }
  UK:  { consumer_duty_assessment: required }

The important property is that adding a market means adding a policy entry and running the test suite, not forking the service.

A prompt for comparing your exposure across markets

You are a financial services regulatory analyst with cross-border
experience. Compare how the following product would be treated in
different jurisdictions.

Product: [DESCRIBE THE PRODUCT AND THE AI COMPONENTS]
Target markets: [LIST JURISDICTIONS]

For each jurisdiction, give me:

1. Whether the AI component would be classified as high-risk or
   equivalent, and under which instrument.
2. Whether a fully automated decision is permitted, and what human
   review right applies.
3. What explanation must be given to a rejected customer, and in
   what form.
4. Whether the data can lawfully leave the jurisdiction to reach a
   hosted AI API.
5. The single largest compliance cost difference between this market
   and the others.

Finish with a table showing which markets are cheapest to enter and
which are most restrictive. State where your information may be out
of date.

Where the regimes genuinely conflict

Most differences are a matter of degree. A few are real conflicts that force architectural decisions.

Data localisation versus centralised models. Where a jurisdiction requires financial data to remain onshore, you cannot call a hosted API in another region. Options are regional model deployment, self-hosted open-weight models, or excluding that market. This is the most common reason serious fintechs run open models.

Right to erasure versus trained models. A model trained on personal data cannot easily forget one individual. Positions differ on whether a trained model constitutes personal data. Practical mitigations: train on aggregates, retain the ability to retrain without a subject, or avoid training on identifiable data at all.

Bias testing versus data minimisation. To test for discrimination you generally need the protected characteristic. To comply with minimisation you should not hold it. Jurisdictions resolve this differently, and some permit collection specifically for testing. Get advice; do not resolve it by assumption.

The compliance cost ladder

Rough ordering of how expensive it is to enter each market with an AI-driven credit product, from a standing start:

This is a planning heuristic, not a ranking of regulatory quality. Burden and protection are not the same thing.

What to build regardless of jurisdiction

A common core satisfies most regimes and costs little more than doing it badly:

• Immutable decision logs — inputs, model version, policy version, score, threshold, outcome, any override and who made it.
• Reason codes generated at decision time, not reconstructed later.
• A real human review path with capacity to actually review.
• Scheduled bias testing with results retained, whether or not currently mandated.
• Model documentation covering purpose, data, limitations, known failure modes and monitoring.
• A defined retraining and rollback process.

Firms that build this early enter new markets by adding configuration. Firms that do not rebuild the product each time.

Sources

Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which are primary-sourced and which are industry reporting.