Calcolatore di utilizzo del credito

Questo strumento accetta ogni conto revolving come una riga con un balance e un credit_limit, somma entrambi i lati e restituisce l'utilizzo come rapporto decimale e come percentuale, più il credito disponibile restante, una fascia da eccellente a over-limit e il rimborso necessario per raggiungere le soglie comuni del 30 per cento e del 10 per cento.

Che cosa significa l'utilizzo del credito e come si costruisce il rapporto

In simboli, utilization_ratio è uguale a total_balance diviso per total_credit_limit, e utilization_percent è quel rapporto per cento. Una verifica svolta è una Visa con saldo di milleduecento su un limite di quattromila e una Mastercard con ottocento su duemila: i saldi combinati sono duemila, i limiti combinati sono seimila, il rapporto è un terzo e utilization_percent è circa 33.33. Ciò sta appena sopra la soglia comune del 30 per cento, quindi paydown_to_30 è duecento e paydown_to_10 è millequattrocento. Quando un saldo supera il proprio limite il conto è over-limit, la percentuale va oltre cento, available_credit su quella riga è zero e over_limit_amount registra l'eccesso.

Contratto di ingresso, campi di risposta, fasce ed errori

Il name facoltativo etichetta la riga nel dettaglio per conto; se omesso, il motore scrive Account 1, Account 2, e così via. Si accettano da uno a cinquanta conti. Invii in POST un corpo JSON con un array obbligatorio, accounts (alias items, list e cards). Ogni riga è un oggetto con balance, un numero finito maggiore o uguale a zero (alias outstanding e amount), e credit_limit, un numero finito strettamente maggiore di zero (alias limit e creditLimit). Imposti in via facoltativa target_percent (alias target) alla soglia usata per paydown_to_target; il valore predefinito è 30 e deve stare nell'intervallo semiaperto (0, 100]. Imposti in via facoltativa decimals a un intero da zero a otto per i totali in stile valuta e utilization_percent; il valore predefinito è due, mentre utilization_ratio è sempre arrotondato a sei cifre. Il motore somma ogni balance e ogni credit_limit, forma il rapporto e ricava available_credit come resto non negativo dei limiti meno i saldi, over_limit_amount come eccesso non negativo dei saldi sui limiti, e le cifre di rimborso come il massimo tra zero e il saldo meno k per cento dei limiti combinati, per k di 10, 30 e l'obiettivo scelto. band è excellent al 10 per cento o meno, good al 30 o meno, fair al 50 o meno, high al 75 o meno, very_high al 100 o meno, e over-limit sopra 100. I booleani under_10_percent e under_30_percent confrontano la percentuale grezza con quelle due soglie con un epsilon minuscolo, così un portafoglio esattamente al 30 per cento non inciampa nella polvere in virgola mobile. highest_account e highest_utilization_percent segnalano la carta più calda, così Lei vede una carta di negozio al massimo nascosta in un rapporto complessivo calmo. I campi di tipo denaro usano l'arrotondamento half-up una sola volta dai valori IEEE grezzi, così i goldens restano stabili tra i runtime. Accounts mancanti, un elenco vuoto, una riga che non è un oggetto, un balance o credit_limit mancante o non finito, un saldo negativo, un limite zero o negativo, più di cinquanta righe, oppure un target o decimals fuori intervallo falliscono con invalid_input nominando il campo e non vengono fatturati.

Dove un calcolatore di utilizzo del credito merita il proprio posto

Le unità TVM di preparazione agli esami e di aula hanno bisogno di un oracolo deterministico che tratti i limiti inutilizzati come parte del denominatore, rifiuti un limite zero invece di dividere per zero e restituisca sia la percentuale del portafoglio sia la carta più calda. Lo abbini al Suo estratto di bureau quando la domanda è che cosa i bureau vedono già, e usi questo calcolatore quando la domanda è che cosa un insieme noto di saldi e limiti revolving implica adesso. I consulenti del credito e i coach di enti non profit usano l'endpoint per mostrare a un cliente quanto pagare in questo ciclo per scendere sotto il 30 per cento o il 10 per cento prima di una consultazione ipotecaria, senza aprire un foglio di calcolo. I team di prodotto e di sottoscrizione inviano l'API JSON a lotti su estratti di estratto conto per segnalare portafogli il cui rapporto complessivo sembra in ordine mentre una carta è over-limit. Poiché l'implementazione è parse puro di livello A, ogni chiamata riuscita costa il prezzo base pubblicato $0.002 senza token di modello né rete in uscita, e una convalida fallita non consuma il saldo. Tenga le richieste piccole e fissi utilization_percent più paydown_to_30 nei test. Questo strumento non estrae un rapporto di credito, non invecchia il punteggio e non modella le linee di utente autorizzato, le svalutazioni né la differenza tra i saldi di estratto segnalati e il saldo in tempo reale di oggi.