> ## Documentation Index
> Fetch the complete documentation index at: https://docs.capcells.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Markets
> One platform, many markets: how the rules of a market are selected, what a market changes, and what a market pack carries.
A **market** is where you lend. The Platform is one implementation everywhere; what belongs to a market is rules, and every rule a market sets travels through one door: the jurisdiction each loan states.
## The jurisdiction
Every issuance states its `jurisdiction`: ISO 3166-1 alpha-2, with up to two subdivisions, `MX`, `DE`, `DE-BY`. The statement selects the market's rules at pricing, and [what it selected is frozen into the loan](/lending/loans) as its `regime`: a later change in a rule reaches new loans only, and two loans issued a year apart under one jurisdiction can lawfully differ.
A jurisdiction the rule tables do not cover refuses issuance. A holiday calendar alone is not enough, a market the Platform cannot charge lateness in is not a market it lends in.
## What it changes
Six rules, each selected by the jurisdiction and nothing else:
| Rule | What it decides | Where it is documented |
| - | - | - |
| The penalty rule | The base lateness accrues on, whether it capitalises, the conditions for calling the balance, and the ceiling on the rate | [Delinquency](/lending/delinquency) |
| The allocation order | The waterfall a receipt settles under | [Payments](/lending/payments) |
| The disclosure figure | The cost figure quoted on every loan, the CAT, in Mexico | [Pricing](/lending/pricing) |
| The uncollected fee | What early repayment does to the origination fee | [Pricing](/lending/pricing) |
| The tax rules | Which `tax` a loan may state: the cases the market's law has, the general one first | [Taxes, below](#taxes) |
| The holiday calendar | Which days collect, and where `due_on` moves | [Pricing](/lending/pricing) |
All six stand for `MX`, and `MX` is the only market the Platform lends in. The `DE` and `DE-BY` calendars exist as fixtures for the subdivision hierarchy, not as maintained markets.
[Read a market's rules](/api-reference/markets/read) before you price a term on them: the penalty cap's form, the base, capitalisation, whether a late fee may stand beside a penalty rate, acceleration, the tax rules, the disclosure convention and the calendar's last covered day, each marked with whose rule it is and whether the Platform holds it provisional.
### Taxes
Every issuance states its `tax`: a rate and the components it applies to. The `tax` must be one of the rules the loan's jurisdiction admits, compared whole: the rate and the set of components together, in any order.
| Market | Rules admitted, general case first |
| - | - |
| `MX` | 16% on `interest`, `fee`, `penalty`, `late_fee` · 8% on the same four, the border region · 0%, an exempt borrower |
| `ES`, `PH`, `UZ` | 0% on all four: the market exempts lending |
Which case applies is your knowledge of the borrower, so you state it. What the cases are is the market's law, so the Platform states it. There is no default, even where a market admits one rule: an exempt borrower is a rule of zero, stated.
A component your product can never charge may be left out. A version with no late fee lets a rule omit `late_fee`; a version with no origination fee and no rollover fee lets it omit `fee`. Such a rule taxes exactly what the admitted rule taxes. Leaving out a component the version does charge is refused naming it.
| Code | When |
| - | - |
| 422 `tax_rule_not_admitted` | The `tax` is not one of the rules the jurisdiction admits. The error names the jurisdiction and every rule it admits, or the component left out |
| 422 `no_tax_rules` | The Platform asserts no tax for the jurisdiction |
A preview refuses exactly as an issuance does. An issued loan keeps the rule it was issued under, whatever the market admits later.
The rules are conservative readings pending a regulatory pass, like the moratory-interest reading on [Lending in Mexico](/lending/mexico). A counsel who reads a market otherwise changes the rule in a release; no calculation changes.
### The calendar horizon
The MX holiday table is supplied from `2026-01-01` to `2030-12-25`, and that last day is the calendar's **horizon**: the last day the Platform has data for.
A date past the horizon is refused, not treated as an open day. A term whose schedule, or whose tolerance end, or whose rollover segment, would fall past it is refused with 422 `beyond_horizon`, naming the date, the horizon and the jurisdiction. The horizon is therefore the effective limit on a term: on any given day, the longest loan you can issue is one whose last date lands on or before it.
```json 422 theme={null}
{
"error": "calendar: date lies past the calendar's horizon: 2031-01-01 lies past 2030-12-25, the last day MX covers",
"code": "beyond_horizon"
}
```
The alternative was worse. A day the table has never named is not a day it has said is open, and treating it as open put due dates on bank holidays nobody had looked up, `2029-01-01` and `2030-01-01` among them. [An issued schedule is frozen](/lending/loans), so those dates would never have corrected themselves.
The table is extended by a release, and the Platform refuses to start when the market it lends in has less than a year of calendar left. Days for `2029` and `2030` are computed from the banking calendar's own rule; a day proclaimed differently later is appended, and by the freezing rule it moves collection attempts and never an issued due date.
## The registry
The registry answers a different question, and the two must never be confused: the jurisdiction above is where a **Loan** is governed; the registry is who may **onboard**. 50 countries, each entry carrying two flags, and the tax rules where the Platform asserts them.
| Flag | What it states |
| - | - |
| `has_pack` | The country carries a market pack, asserted, below |
| `lending_supplied` | All six rule tables above stand for it, computed, never asserted. True for `MX` alone |
An entry whose tax the Platform asserts also carries `tax_rules`: the rules above, in exactly the shape of a loan's `tax`, the general case first. Copy one into an issuance body as it stands. An entry without them carries no field at all.
The registry is read at the Console door, `GET /console/v1/countries`, ordered by country code, needing a usable console token and nothing else, and it is the list [the company profile](/getting-started/company-profile)'s `country_code` must come from.
## Market packs
Four countries carry a **pack**: the market worked out for onboarding. A pack offers legal entity forms, and every pack is a market whose tax the Platform asserts.
| Pack | Legal entity forms | Tax rules |
| - | - | - |
| `MX` | Seven, from `S.A. de C.V.` to `SOFOM E.N.R.` and `SOFIPO` | 16%, 8%, exempt |
| `ES` | The Spanish forms | Exempt |
| `PH` | The Philippine forms | Exempt |
| `UZ` | Five, in Latin script: `MChJ`, `AJ`, `Mikromoliya tashkiloti`, `Lombard`, `Bank` | Exempt |
The entity forms suggest and govern nothing: a form off the pack's list is accepted on [the company profile](/getting-started/company-profile). The tax rules are not a suggestion. They are the [Taxes](#taxes) table above, and issuance holds a loan's `tax` to them.
The entity forms are conservative assertions pending a regulatory pass. They orient an onboarding; they are not the Platform's statement of a market's law.
`MX` is the launch market, and `UZ` is the next. `ES` and `PH` are worked out for onboarding in parallel. Whether the Platform can lend in any of the three is never asserted in the registry. It is computed from the rule tables, and today it is false for all three. **A pack is not a market the Platform lends in**: the flag that says where lending is supplied is `lending_supplied`, and nothing else does.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.