By Eddie Arenas, CEO of Quarks Data
For decades economics assumed that capital was the constraint on growth. It rarely is. What is scarce is not money, but productive knowledge: the capacity to do things others cannot do. That knowledge is not bought in a market or downloaded in an afternoon. It accumulates, gets embedded in people and systems, and is sustained by effort.
A bank is the purest illustration of this idea. Money is its most abundant and least distinctive input: almost every bank has access to essentially the same raw material. What separates an excellent bank from a mediocre one is not how much it can lend, but how well it knows to whom. That capacity, the ability to know to whom, is a productive asset. And today it lives, increasingly, in data.
In 2022, as Synergy Data Analytics (the company that is now Quarks Data), we built the credit scoring engine for Argentina's most important bank. Confidentiality agreements prevent us from naming it. What follows is both the technical account of how such a system is built and the economic argument it illustrates: in banking, knowledge, not capital, is the scarce factor.
The problem is not information, it is the capacity to use it
One distinction economics learned late is useful here. Information is codifiable: it travels cheaply, gets copied, gets transmitted. Productive knowledge, know-how, is tacit: it lives in networks of people and in the systems they build, and it resists transfer. A bank does not lack information about its borrowers. It has too much. What is hard is turning that scattered information into a single, reliable, repeatable judgment about each individual. That conversion is the capacity. Scoring is the mechanism that produces it.
Formally, the goal was not a score but a calibrated, time-stable probability of default (PD). The definition of default was explicit and auditable: 90 days or more past due within a 12-month observation window, from a cutoff date. That definition governs everything else. Getting it wrong contaminates the entire system without any metric flagging it.
The infrastructure where knowledge accumulates
Knowledge that aspires to be productive needs a place to live. Ours was a Lakehouse architecture on Databricks with Apache Spark as the distributed compute engine, because the volume (millions of individuals with history, cross-referenced against several sources) did not fit on a single machine.
The organization followed the medallion pattern on Delta Lake. The bronze layer receives raw ingestion from sources without transformation, preserving the original data with traceable lineage. The silver layer reconciles: it cleans, deduplicates, resolves identity across sources and unifies the individual key. The gold layer produces the analytical base table (ABT) with the 360+ features and the target, built with point-in-time correctness.
Delta Lake provided ACID transactions, time travel to reproduce any historical run and schema enforcement so a source change would not silently break the pipeline. MLflow logged every experiment with its hyperparameters, metrics and artifact, so every score was reproducible and auditable months later. In banking this is not a luxury, it is a requirement: knowledge that cannot be reconstructed is not an asset, it is an anecdote.
Encoding what the bank knows: the 360 features
Each feature is an attempt to encode a fragment of tacit knowledge about a borrower's behavior. Power did not come from any single source but from their combination: Experian's credit bureau, giving us the individual beyond their relationship with the bank; the financial system's debtor registry with each debtor's regulatory situation and classification; and the bank's own data on the customer's relationship with the institution.
From that combination we derived more than 360 variables per individual, grouped in families: sociodemographic and stability, payment behavior with 3, 6 and 12 month trajectories, exposure and indebtedness, utilization ratios, credit appetite measured by recent inquiries, delinquency history in its recency and severity, and derived variables capturing interactions.
The serious work is not having 360 features, but building them with temporal correctness. Each one was computed strictly with information available before the cutoff date. A single data point that looks into the future inflates validation performance and collapses in production. For the same reason, the split was out-of-time and not random: you train on older cohorts and validate on later ones, because a risk model is judged by predicting the future, not by interpolating the past.
The model: XGBoost, and the price of opacity
Choosing XGBoost over a logistic regression or a classic WOE scorecard was deliberate. XGBoost captures non-linearities and interactions without hand-specifying them, handles missing values natively (and in bureau data, missing is informative, not noise) and is robust to correlated features and different scales.
Every capacity has its price. XGBoost's is opacity: a logistic scorecard is transparent by design, a tree ensemble is not. In banking that is not negotiable, so it was compensated on two fronts. First, SHAP values to decompose each score into the contribution of each feature, enabling the reason codes required to explain a rejection to the customer and to the regulator. Second, monotonicity constraints on variables where the relationship with risk must respect business logic, sacrificing some raw fit for a defensible model.
Training handled class imbalance with scale_pos_weight instead of aggressive oversampling, which distorts calibration. Hyperparameter search was distributed with Hyperopt on the cluster, with early stopping against a temporal validation set.
From probability to decision: calibration
A well-trained XGBoost orders well, but its raw outputs are not reliable probabilities. Before translating to a score, the PD was calibrated (isotonic calibration on the out-of-time set) so that a 10% PD effectively means 10% defaults observed in that segment. Without that step the ordering is correct but business thresholds are misplaced.
The PD-to-score translation used classic scorecard logic: score = offset + factor · ln(odds), where odds = (1 − PD) / PD and the factor derives from the PDO (points to double the odds). The result is an interpretable, monotonic scale: higher score, lower risk, with a known relationship between points and odds. The bank receives a number it can use for cutoff policies without needing to understand the model internals.
Proof that the knowledge is real: validation
A single number does not validate a risk model. The battery was: discrimination with Gini, AUC and KS, the metric risk looks at first; decile ordering, verifying that default rate falls monotonically as the score rises; stability with PSI between the development population and later cohorts, the early alarm that a model is drifting; and out-of-time backtesting on cohorts the model never saw. Only when all four pass is the model a production candidate.
Governance: knowledge as an asset that is protected
The work involves financial personal data on millions of individuals, bureau data and regulatory information from the system, for the country's largest financial institution. Security was designed in, not added later: processing inside a controlled perimeter with no exfiltration of raw data, encryption at rest and in transit, tokenization and hashing of personal identifiers (the model needs features, not identity), role-based access control under least privilege with table and column level permissions, and complete lineage and audit logs. In banking, being able to answer who touched what and when is as important as the model itself.
Scope and deliverable
The scope was defined narrowly: the universe of individuals in the system over the authorized sources, a fixed cutoff date and 12-month performance window, and the goal of building, calibrating and validating the engine, with documentation and knowledge transfer. Productive operation in the core systems remained on the bank's side.
We delivered a versioned, reproducible model in MLflow, an end-to-end scoring pipeline runnable on Spark, technical documentation and model card a regulator can read and defend, per-individual reason codes via SHAP, a monitoring framework with stability metrics and their alarm thresholds, and knowledge transfer to the bank's team.
Capital is abundant, knowledge is not
It is worth returning to the beginning. A bank does not sell money, it manages risk. Every credit decision is a bet on incomplete information, and the quality of that bet defines the margin: how much it lends, to whom, at what rate, and how much it loses. Money, which looks like the heart of the business, is the easiest thing to obtain. What is hard, what is scarce, what truly distinguishes an institution, is the capacity to turn scattered data into reliable decisions.
That capacity has the nature of know-how: it is not bought ready-made, it is built. It lives in data infrastructure, in features that encode years of behavior, in calibrated models and in the governance that sustains them. A competitor can copy a bank's rate in a day. It cannot copy its capacity to decide well, because that capacity is embedded in a system that took years to accumulate.
That was the work then, as Synergy Data Analytics, and it is the same thesis with which we build decision infrastructure today at Quarks Data. In Latin America, where data is dirtier, more fragmented and more regulated than any manual assumes, this capacity is not just another competitive advantage. It is the condition to compete. Capital will go where knowledge knows what to do with it.