Card fields, credit engine, bureau and transactions
Components with stated weights and knockout rules kept separate
Score, priority band and reason per application
Score on the card, sales queue, AI agent and alerts
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.
Business questions it answers
Ask your agent these questions once the case is live.
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
Where to activate
The score and the points per component go back to the card or the deal, and the sales queue sorts by them.
Explains why an application got its score and which rule knocked it out, with the weights from the context document.
Daily and per-batch check of the engine log: an approval rate by bank or segment that breaks from the norm goes to Slack.
The calculation is simple SQL. The work is in settling the weights with the team, cleaning the card fields and building the write-back to the pipeline. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
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.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Score components: a real example
Vehicle-backed lending. Weights add up to 100; each company calibrates its own.
Definitions
Pitfalls that already happened
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.
Define which score is official and read the field from the source.
Bank transactions repeated during sync and with an inverted sign made the detected salary of some users double, and the limit rose with it.
Deduplicate by user, date, account and amount, normalize the sign and rebuild the history.
Users who declared being paid twice a month were classified as every 14 days, and collection was scheduled before the salary landed.
Classify by the median interval between deposits.
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.
Rebuild the features point in time and store the decision snapshot.
Reused decisions came back in under a second and pulled the engine's average response time down.
Exclude responses of up to 1 second from the average and report them separately.
In a monthly propensity list, the same customer appeared in several likely months and was approached more than once.
One customer per list, in the month and product with the highest likelihood.
Acceptance test
The case is done when every item passes.
- 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.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
Scoring and prioritization - The official score for product <product> is <card field / engine tier / score table>. Never recalculate a score the source already stores. - Score = sum of the components, from 0 to 100. Weights: <component: weight>. Each component's points are in their own columns; use them to explain the score. - Knockout rules stay outside the sum: <list>. 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: <value>. - Delinquency by band is measured in the decision's vintage (FPD and delinquency over <N> 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: - <client>: for product <product>, the score comes ready in card field <field>. - <client>: the engine tier sets the limit; the limit progression for good payment is in <table>. - <client>: the pay frequency comes from <source> and takes precedence over the declared one.
Build the "Scoring and prioritization" case in my Nekt workspace following the rules at https://academy.nekt.com/en/industrias/financeiros/score-priorizacao.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.
Variations
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.
Likely month and line of purchase from the time pattern of policies, with a monthly outreach list without repeated customers.
Levels by number of event or training participations, per normalized CNPJ (company tax ID), to prioritize who gets a credit offer.