> ## 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.
# Facilities
> The standing grant a client draws several loans from: what it fixes, how its headroom falls, and why it expires.
A **Facility** is a grant your tenancy creates from an approving decision, or from a `refer` a person [resolved](/lending/decisions#resolving-a-refer) as an approval: one amount at one price, for one client and one product, inside a validity window. Several loans may be issued under it.
It exists so that one scoring event serves several issuances. A client is decided once, granted an amount, and then buys several times under it, each purchase becoming a loan, none of them exceeding what was approved and none priced by anything other than the decision that approved them.
## The grant
Five things come from the decision and are not restated at creation. A grant that restated what was approved would be a grant that can disagree with it. For a resolved `refer`, the amount and the rate are the resolution's.
| Fixed by the decision | What it does at issuance |
| - | - |
| The client | An issuance for anybody else is refused |
| The product configuration | An issuance under another product is refused; a later version of the same product is admitted |
| The amount | It is the ceiling every loan under the grant is drawn against |
| The rate | A loan stating any other rate is refused, whatever the configuration's corridor admits |
| The currency | An issuance in other money is refused |
You state the window, because it is the one thing the decision has no opinion about.
A grant does **not** fix the term. The term stays what it always was: your selection at issuance, validated against the configuration version the loan names. A term is a property of the loan and not of the exposure.
The rate is fixed because a grant of an amount with no price is a grant priced by whoever calls issuance a month later. That is exactly the term-tampering a recorded decision exists to prevent, arriving through a door left open.
## Headroom
**Headroom** is the grant's amount minus the sum of the original principals of every loan ever issued under it, whatever each loan's later state.
A grant of MXN 10,000.00, drawn twice:
| Event | Drawn | Headroom |
| - | - | - |
| Granted | MXN 0.00 | MXN 10,000.00 |
| A loan of MXN 3,000.00 issued | MXN 3,000.00 | MXN 7,000.00 |
| A loan of MXN 2,000.00 issued | MXN 5,000.00 | MXN 5,000.00 |
| The first loan repaid in full | MXN 5,000.00 | MXN 5,000.00 |
| The second loan cancelled | MXN 5,000.00 | MXN 5,000.00 |
Nothing that happens to a loan restores capacity. Repayment, prepayment, reversal, cancellation, write-off and acceleration all leave the two figures exactly where issuance left them.
One loan is the exception, and it is a loan that never began. A loan issued with `hold_until` draws its grant like any other, so a second issuance cannot spend what the hold reserves. If it is [voided](/api-reference/loans/void) before anybody signs it, its principal stops counting. An issuance dated after a hold's last day also sees that hold released; the facility read takes no date, so it counts an expired hold until you void it.
That is the whole design rather than an omission. Freeing capacity is a new decision and a new facility, which closes the class of reversal edge cases a self-restoring limit would open, and it means the grant records what was drawn without having any opinion about what became of it.
A one-draw grant is not a revolving limit. A tenancy expecting repayments to free capacity will find the grant spent; the answer is a [line](#lines), or a new application under a new reference.
## Lines
A **line** is the grant whose capacity comes back. Ask the decision for a `limit` rather than a principal — the approval is the approving band's ceiling, bounded by the product's highest principal — and create the facility from it with `line: true`.
A line's headroom is its amount minus the principal still **outstanding** on the loans drawn from it, as of the day asked about:
| Event | Outstanding | Headroom |
| - | - | - |
| A line of MXN 10,000.00 granted | MXN 0.00 | MXN 10,000.00 |
| A purchase of MXN 4,000.00 drawn | MXN 4,000.00 | MXN 6,000.00 |
| MXN 1,500.00 of its principal repaid | MXN 2,500.00 | MXN 7,500.00 |
| That receipt reversed | MXN 4,000.00 | MXN 6,000.00 |
Principal a receipt repays, a return unwinds or a prepayment settles comes back from that day; a cancelled or voided draw gives back all it took. A written-off, accelerated or ceded draw gives back nothing: the money is lost, demanded or sold, not repaid.
A line may be drawn until its expiry, up to **180 days** after the decision rather than 30, because every draw re-reads the Platform's own book: the [client guards](#client-guards) the version states are held at each draw, and a draw is refused `client_overdue` while any loan of the client's stands overdue, whatever the version says. A bureau is not re-read, which is why the bound is not longer.
A line is renewed by a new limit decision and a new line naming the old one in `supersedes`. What is still outstanding under the old line counts against the new one, so a renewal mints nothing: a line of MXN 10,000.00 with MXN 3,000.00 outstanding, renewed by one of MXN 15,000.00, opens with MXN 12,000.00 of headroom. The old line refuses draws anchored on or after the day the new one opens.
## The window
The window bounds the days a loan may be **drawn** on, measured against the loan's own anchor date rather than the day the request arrives. A loan issued inside it may mature long after the expiry.
Between creating a grant and any draw under it, the Platform re-reads nothing about the client. Whatever the decision read: what you declared, the Platform's own book, or a bureau report. A fact that turned against the client after the grant, an arrear taken elsewhere, an income that ended, is as invisible on the last draw as on the first.
So the length of the window is the whole of the Platform's answer to staleness, and the expiry may sit no more than **30 days** after the decision's `bound_from`: the day the application states where that is earlier than the day the decision was recorded on, and the recording day otherwise. For a resolved `refer`, the 30 days count from the day it was resolved, which is when anything was approved.
The number is the conservative reading and it is marked for the jurisdictional review. Products that hold a pre-approval open about this long re-pull the bureau and re-score at every drawdown: the grant there is a price quote plus a promise to look again. The Platform does not look again, so a longer window carrying less evidence would be the wrong end of that trade twice over.
## Arrears
An issuance naming a grant is refused while any loan already issued under that grant stands overdue on the new loan's anchor date. It is admitted once the arrears are cured.
Headroom alone cannot see this. It falls when a loan is issued and never rises, which makes it an exact record of what was drawn and no record at all of whether any of it is being paid: a client sixty days behind on the first draw has the same headroom as one who has paid every instalment on time.
The bar answers for one grant. A loan overdue under a *different* facility does not bar this one, because a grant answers for what was drawn under it and the Platform states no ceiling across a client's grants.
There is no limit on how many loans may stand open under one grant at once. A count across the client's whole book is the version's to state — see [client guards](#client-guards).
## Client guards
A configuration version may hold every issuance under it to three guards across the client's **whole book** — every loan of theirs under your tenancy, whatever product or grant it was issued under:
| Field | Refused when | Code |
| - | - | - |
| `max_open_loans_per_client` | The client already holds that many open loans, a held one among them | `client_open_loans` |
| `max_outstanding_per_client` | The principal outstanding plus this loan would pass the cap | `client_exposure` |
| `refuse_while_any_loan_overdue` | Any loan of the client's stands overdue on the anchor | `client_overdue` |
They are read at issuance and at the preview, under the client's lock, and never at the decision: the book moves between the two, and an approval taken while the client was under the count is no promise the count still holds on the day she signs. Approvals in flight cannot stack past them. A version stating none issues exactly as before.
The guards read the whole book whichever version states them, so state them on every version a client may draw under.
## Several grants
A client may hold several live facilities. Each caps only the loans issued under it, creating one ends nothing, and the Platform states no ceiling across them.
This is a stated position rather than a silence. What a later decision means for an earlier grant is a real question, and the answer is: nothing. The grant was made on a decision that stands recorded; a subsequent decision, better or worse, is a separate fact about a separate application.
A tenancy that needs a ceiling across a borrower's grants enforces it in its own system, out of the totals the list and the read serve.
## Requiring one
A configuration version can state that loans under it are issued only under a facility. Set `requires_facility` on the version, and an issuance naming no grant is refused naming the requirement.
Absent, the field means the facility is optional per loan, which is what every configuration written before the field existed says. It reaches a loan the way every configured term does: through the version the loan was issued under, so a later version adding the requirement leaves loans already issued standing.
## What is checked
Naming a `facility_id` on an issuance or a preview adds these checks. Each refusal names what did not fit.
| Refused when | The refusal names |
| - | - |
| The grant does not exist for your tenancy | The identifier, and nothing about the grant |
| The grant's client is not the loan's | Both clients |
| The loan's configuration is not the grant's | Both configurations |
| The currency differs | Both currencies |
| The stated rate is not the grant's | Both rates |
| The loan's anchor lies outside the window | The window and the anchor |
| The principal exceeds the remaining headroom | The amount, what was drawn, and what remains |
| A loan under the grant stands overdue on the anchor | The loan, its overdue period and the day it fell due |
A preview applies every one of them and refuses with the same error the issuance would give. It reserves nothing: two previews against a grant with room for one loan both answer, and only one issuance is then served.
The headroom check is serialised with the client's other loan-level writes, so two concurrent issuances cannot both pass the same remaining figure.
## The decision
A loan may name the decision it was issued under, with or without a grant.
* Under a grant, the loan always ends up naming that grant's decision. Stating it is admitted, stating a different one is refused naming both, and stating none records the grant's own.
* Outside a grant, the reference binds nothing and is not verified. Naming a decision changes nothing about what is validated, and the Platform does not check that it exists.
It is there so that what became of a loan can be joined to what decided it. Nothing reads that join today. A column now costs a column; the same column in two years costs the two years of history that were never captured.
## Limits
| It does not | Instead |
| - | - |
| Entitle anybody to a loan | It caps. You decide whether to issue |
| Change after creation | It ends by its expiry passing, and in no other way: there is no edit, revocation, freeze or early close |
| Restore capacity when a loan ends | A new decision and a new facility |
| Cap a client's exposure across grants on its own | Each grant caps its own loans; a version's `max_outstanding_per_client` caps the client's whole book |
| Re-check a bureau before a draw | The Platform's own book is re-read on every draw from a line; a bureau is not |
| Track an outstanding balance on a one-draw grant | Headroom counts original principals. A line counts what is outstanding |
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.