--- id: financeiros/score-priorizacao industry: Financial services usage: widely used effort: medium grain: Application or customer x calculation date; decision log per application to calibrate the cutoff --- # Scoring and prioritization A 0 to 100 score per application or customer, with the weight of each component in plain view, written back to the card so the team first approaches whoever is most likely to become a good loan. ## Executive summary **For:** Banking correspondents, lending and earned wage access fintechs, and brokers that need to decide whom to approve or whom sales calls first. **What it solves** - Sales works the queue in order of likelihood to become a loan, not in order of arrival. - Every score explains itself: you can say how many points came from collateral, income and LTV. - The approval cutoff is evaluated against the delinquency that followed, by score band. **Why it matters:** In lending, the loan officer's time is the scarce resource and most applications never become an issued loan. A score nobody understands becomes a black box and the team goes back to choosing by gut feeling. With an explainable score written on the card itself, prioritization becomes routine, and the same data shows whether the cutoff is approving people who later fall behind. **Business questions it answers** - Which applications should sales tackle first today? - Why did this application get this score? - What is the score distribution of the applications that came in this month? - Is the score cutoff approving people who later fall behind? - Which rule declines the most applications, and how much volume does that cost? - Did the approval rate of any bank or segment change from yesterday to today? **What you need** - The pipeline connected to Nekt (Pipefy, Zeev or core system), with the collateral, income and credit amount fields - The score components and weights agreed with credit and sales - To calibrate the cutoff: the decision log and the delinquency of disbursed contracts **What you get** - A table per application with the score, the points for each component and the rules that failed - The score written back to the card or the CRM, ready to sort the queue - An AI agent that explains the score of any application - Alerts when the approval rate of a bank or segment breaks from the norm ## Detailed ### The problem The data that decides a loan is scattered: collateral value and year on the card, income typed as text, the bureau score in a log, salary hidden in bank transactions. Each analyst weighs things differently and the queue moves in order of arrival. When someone does build a score, it is usually a single formula with no explanation, recalculated on top of the score the pipeline already stored, and evaluated with data that did not exist on the day of the decision. ### Business rules 1. **Components with stated weights that add up to 100.** The score is the sum of components, each with a maximum score written in the context document. A real example for vehicle-backed lending: collateral value 20, vehicle year 20, vehicle type 15, collateral quality 15, monthly income 15, employment status 7, location 3, LTV 3, purpose 2. Store each component's points in its own column, next to the total. (Avoid: A single formula that returns only the final score.) 2. **A knockout rule is not a weight.** Some conditions sink the application regardless of the rest: a vehicle that is too old, a collateral type the funding does not accept, collateral not in the customer's name or with an outstanding balance, an employer not on the accepted list, salary below the minimum, a failed bureau score. Treat them as a heavy penalty or a cutoff, with one flag per rule. Approved on score means every rule passed, and the decline reason is the rule that failed. (Avoid: Diluting the knockout rule as a small weight that another component can offset.) 3. **Card fields normalized before scoring.** Card values arrive as Brazilian-formatted text ('1.234,56', sometimes with R$ and the select field's brackets). Remove the thousands separator, replace the comma with a period and convert. LTV = requested credit amount / collateral value. An outstanding balance on the collateral lowers collateral quality, not the credit amount. (Avoid: Converting the text directly and scoring null income as zero.) 4. **Missing data has its own score and flag.** An application without income or without the collateral year gets the component's minimum score and a missing-data flag, never the average. Measure each component's coverage: a component filled on only a few cards does not discriminate anyone and its weight should be reviewed. (Avoid: Ignoring the empty component and rescaling the score of the others.) 5. **If the pipeline already stores a score, read it, do not recalculate.** When the card already carries a weighted score calculated by another process, or the credit engine returns a tier that sets the limit, that is the official score. Read the field directly from the card or the engine log. Recalculating on top creates two scores for the same application and sales does not know which one counts. (Avoid: Rebuilding in SQL a score that already exists in the operational system.) 6. **Score as of the decision point in time.** To evaluate the cutoff, each component needs the value available on the decision date. Salary detected in transactions is rebuilt point in time: deduplicate repeated transactions, normalize the sign (credits positive) and recalculate with the history up to that date. Evaluating with today's data makes the model look better than it was. (Avoid: Joining the old decision with the current salary and customer record.) 7. **Pay frequency from deposits, not from what was declared.** Someone paid on the 15th and the last day of the month (semimonthly) is different from someone paid every 14 days. Classify by the median interval between salary deposits: 15 to 16 days is semimonthly on fixed dates; 14 days is biweekly. The frequency sets the collection date and feeds the capacity score. (Avoid: Treating every twice-a-month payment as biweekly.) 8. **Calibrate the cutoff by band and by vintage.** Group decisions into fixed score bands (for example, every 20 points, rounding up) and measure per band: approval, amount disbursed and subsequent delinquency (FPD and delinquency past the policy cutoff) in the decision's vintage. Instant engine responses (up to 1 second, reused decisions) are excluded from the average response time. (Avoid: Changing the cutoff by looking only at the approval rate.) 9. **Write-back in the pipeline's format.** The score goes back to the operational system as one row per card and field: (card_id, field_id, new_value), ready for Pipefy's batch field update or for the CRM property. Send only what changed since the last send and store the calculation date with the score. (Avoid: Exporting a spreadsheet with every score for someone to paste into the card.) ### Score components: a real example Vehicle-backed lending. Weights add up to 100; each company calibrates its own. - **Market value of the asset** → Collateral (`20 points`) - **Heavy penalty for an old vehicle** → Vehicle year (`20 points`) - **Motorcycles are heavily penalized** → Vehicle type (`15 points`) - **In the customer's name with no outstanding balance** → Collateral quality (`15 points`) - **Declared or detected monthly income** → Income (`15 points`) - **Employment type and occupation** → Employment status (`7 points`) - **Market served** → Location (`3 points`) - **Credit / collateral** → LTV (`3 points`) - **Use of the money** → Purpose (`2 points`) - **Employer not on the list, salary below the minimum, failed bureau score** → Knockout rules, outside the sum (`flag per rule`) ### Definitions | Metric | Definition | |---|---| | Application score | sum of the component points, from 0 to 100, per card and calculation date | | Component points | score obtained in the component, between zero and the stated maximum weight, per card | | LTV | requested credit amount / collateral value, per application, on the calculation date | | Approved on score | true when every knockout rule passed, per application | | Decline reason | the knockout rule that failed, per application; if more than one, the first in the policy's order | | Score band | the fixed point range (for example, every 20) the score falls into on the decision date | | Approval rate by band | approved applications / evaluated applications, by score band and decision month | | Delinquency by band | contracts with FPD / disbursed contracts, by score band at decision and vintage | | Component coverage | cards with the component's data filled / scored cards, in the period | ### Pitfalls - **Two scores for the same card.** The card already carried a weighted score filled on almost every application, and a transformation calculated another score on top. Sales started seeing two different numbers. How to avoid: Define which score is official and read the field from the source. - **Doubled salary.** Bank transactions repeated during sync and with an inverted sign made the detected salary of some users double, and the limit rose with it. How to avoid: Deduplicate by user, date, account and amount, normalize the sign and rebuild the history. - **Semimonthly treated as biweekly.** Users who declared being paid twice a month were classified as every 14 days, and collection was scheduled before the salary landed. How to avoid: Classify by the median interval between deposits. - **Cutoff evaluated with today's data.** The cutoff analysis joined old decisions with the current customer record. The score seemed to separate good and bad payers better than it did at the time. How to avoid: Rebuild the features point in time and store the decision snapshot. - **Unrealistic response time.** Reused decisions came back in under a second and pulled the engine's average response time down. How to avoid: Exclude responses of up to 1 second from the average and report them separately. - **A list with repeated customers.** In a monthly propensity list, the same customer appeared in several likely months and was approached more than once. How to avoid: One customer per list, in the month and product with the highest likelihood. ### Acceptance test - [ ] For every scored card, the sum of the component points equals the score, and no score falls outside 0 to 100. - [ ] Every application in an open stage has a score or a missing-data flag, and each component's coverage appears in the report. - [ ] Recalculating the score for a past date returns exactly the same score. - [ ] After the write-back to the pipeline, the value on the card equals the table's value in a sample of at least 50 cards. - [ ] The sum of applications by score band equals the total of evaluated applications in the month. ### Context document ```text Scoring and prioritization - The official score for product is . Never recalculate a score the source already stores. - Score = sum of the components, from 0 to 100. Weights: . Each component's points are in their own columns; use them to explain the score. - Knockout rules stay outside the sum: . Approved on score = all passed. Decline reason = the rule that failed. - Missing data gets the component minimum and a flag. Never fill with the average. - LTV = credit amount / collateral value. Card values come as Brazilian-formatted text: normalize first. - To evaluate the cutoff, use the features as of the decision date, never the current ones. - Score bands: every <20> points. Current cutoff: . - Delinquency by band is measured in the decision's vintage (FPD and delinquency over days). - Engine response time excludes responses of up to 1 second. - Never show a full CPF (individual tax ID); use the hash or the masked CPF. Per-client exceptions: - : for product , the score comes ready in card field . - : the engine tier sets the limit; the limit progression for good payment is in . - : the pay frequency comes from and takes precedence over the declared one. ``` ### Variations - **Machine learning model:** A classifier (random forest or gradient boosting) over the history to list the top third of customers; publish the most important variables next to the list. - **Insurance propensity:** Likely month and line of purchase from the time pattern of policies, with a monthly outreach list without repeated customers. - **Engagement score:** Levels by number of event or training participations, per normalized CNPJ (company tax ID), to prioritize who gets a credit offer.