# Loans ## How loans work in g-banking This is a plain-language walkthrough for players and for anyone new to the resource. Numbers and labels come from your `config`—what you see in game might differ, but the flow is the same. *** ### Applying for a loan Someone opens the banking UI at a bank, goes to the Loans section, picks a **template** (each template is a product: label, max amount, interest, number of installments, how long the loan runs, and so on), and enters **how much** they want within that template’s limits. Before anything is saved, the script checks a few things: * **Credit score** — Each template can require a minimum score. If you’re below it, the application is refused (`insufficient_credit_score`). New players often sit around a middle score until they build history. * **Net worth** — Adds up money in their bank accounts (per your setup). Templates can require a minimum net worth so people aren’t borrowing with empty pockets. * **Job** — If the template lists allowed jobs, only those jobs qualify. An empty list means any job is fine. * **How many loans at once** — There’s a cap (`maxActiveLoans`, often something like 2). **Active** here means anything still in play: pending approval, or already running. If all of that passes, a **loan row** is created in the database. From the player’s point of view, that’s **I applied**. *** ### Instant money vs waiting for approval Your config has a switch: **`approvalRequired`**. * If **`approvalRequired` is false** — The loan goes **straight to active**. The player gets the **principal** paid out (minus any processing fee), and the clock starts for the first installment. No human step. * If **`approvalRequired` is true** — The loan sits in **pending**. **No money is paid out yet.** Someone with access to the admin/owner loan tools has to **approve** or **reject** it first. So **who approves?** — **Staff or the bank owner** (depending on how you set up permissions and whether ownable banks are on). They use the loan management UI: see pending requests, maybe peek at risk info, then approve or reject. Rejecting can carry a reason string for records. When an approver **accepts** a pending loan, the status flips to **active**, timestamps and the next payment due date are set, and **then** the borrower gets the principal (again minus fees). If they’re offline at that moment, payout happens when they’re online and the system resolves them—approval still went through on the server. *** ### Owned banks vs **normal** banks **Normal banks (global loans)**\ When **ownable banks** are off, loan products and rules usually live under **`Config.Banks.Loans`**. Fees from processing can go to your configured **government/society** account. When the player **repays** installments, those repayments can be routed to that same kind of government pot—think **state-backed bank.** **Owned banks**\ When **ownable banks** are on and a location is configured as an owned bank **with loans enabled**, that bank reads its own **`Loans`** block from **`ConfigOwnedBanks`**. Templates and limits can differ per branch. Important differences for owners: * **Approving a loan** can require the **bank vault** to have enough balance, if you turn on **`RequiredBankBalance`** / **`RequiredBankBalanceEnabled`**. That stops owners from approving loans when the business literally doesn’t have cash to lend. * **Paying out** the loan pulls from the **owned bank’s balance** (the script removes the principal from that bank when it pays the player). * **Repayments** split things sensibly: interest (and optional routing of principal) can feed **owner profit** and **bank balance** depending on **`routeInstallmentPrincipalToOwner`** and your setup. Processing fees on payout often stay with the bank or profit, instead of only the government account. So for players it feels the same—apply, pay installments—but behind the scenes **owned banks** tie lending to **that branch’s money**, while **standard banks** lean on **global config and government/society** accounts. *** ### Paying it back Loans are repaid in **installments**. The total to repay is principal plus interest (computed from the template). Each payment chips away at **`remaining_balance`** until it hits zero and the loan is **completed**. * **Due dates** — **`DuePaymentIntervalHours`** (in `LoanSettings`) controls how often the next payment is due after the last one (default behavior in code is on the order of hours; your config may say 12, 24, etc.). * **Paying manually** — The player pays from **bank or cash** (whatever the UI and server allow for that action). If they don’t have enough, they get an insufficient funds path. * **Reward points** — If you configured reward points for loan repayment, paying on time can grant points—nice for retention, optional. *** ### What if they miss a payment? Nothing nasty happens **the second** the clock passes. There’s a **grace period** (`loanGracePeriodSeconds` or `loanGracePeriodHours` in `LoanSettings`). During grace, the loan is still **late** in spirit but the heavy machinery may not run yet. If **`AfterGraceCollection`** is enabled, once they’re **past grace**, the system can try to **pull the installment automatically** from their **bank and/or cash** (depending on `source`: bank only, cash only, or try bank then cash). If **late fees** are enabled, a percentage of the installment (capped by `maxLateFee` if set) can be added. If the money **still** isn’t there after that attempt, the loan can be marked **defaulted**. *** ### Defaulting — what breaks? A **default** is **this loan is in bad standing and there’s still money owed.** * **Credit score** takes a hit (`scoreDecreasePerDefault` from loan config, bundled with the credit service). **Completed** loans do the opposite—they bump the score up (`scoreIncreasePerCompleted`). * **Stats** — Counters like total loans, paid loans, and defaulted loans update for dashboards and risk views. * **Banking lock** — If **`AllowTransactionsWithDefaultedLoan`** is **false** (in `LoanSettings`), someone with an **unpaid defaulted loan** can be **blocked** from transfers, deposits, withdrawals, and similar ATM flows until they fix the situation (e.g. pay down the defaulted loan). If you set it **true**, they can still use banking even while in default—your server’s choice. They can still **repay** a defaulted loan in many setups (the service allows repayment paths for defaulted rows so people can recover). *** ### Credit score — quick mental model * Everyone gets a **score band** (tiers like D through SSS in the default logic—exact letters depend on thresholds). * **Applying** doesn’t magically raise the score; the **template’s minimum** is what gates eligibility. * **Finishing** a loan cleanly **increases** score (configurable bump). * **Defaulting** **decreases** it hard; **missed-payment** adjustments exist in code where you wire them. Admins can use **risk snapshots** (credit + loan counts + late vs on-time style stats) to decide on borderline applications—that’s the **should we trust this character?** panel, not a player-facing minigame. *** ### Tiny example timeline 1. **Alex** applies for a $10,000 car loan template at an owned bank. Approval is required. The request is **pending**; Alex’s account does **not** get $10k yet. 2. **Owner** checks the dashboard, sees Alex’s job and credit are fine, vault has funds, and hits **Approve**. Alex is online—**$10k** (minus fee) lands in their account, first installment due in X hours. 3. Alex pays a few installments on time. **Credit** trends okay; **remaining balance** drops. 4. Alex misses a due date, ignores grace, and auto-collect **fails(over due)**. Loan goes **defaulted**, score drops, and if your config locks banking, Alex **can’t shuffle money** through normal banking until they **pay the defaulted loan** down or you intervene. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://grootdev.gitbook.io/groot-development/assets/g-banking/guides/loans.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.