Skip to main content
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 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: 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 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. 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. 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. 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.
422
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, 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. 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’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. The entity forms suggest and govern nothing: a form off the pack’s list is accepted on the company profile. The tax rules are not a suggestion. They are the 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.