How Open Finance data transformed our credit scoring engine

The problem with bureau-only credit scoring

Traditional credit scoring in Brazil relies on two sources: Serasa and SPC/Boa Vista. These bureaus maintain databases of negative events — defaults, protests, bounced checks, lawsuits. If you have negative records, your score is low. If you don't, your score is... generic.

This binary approach has a fundamental problem: it tells you who defaulted in the past, not who can pay in the future.

Consider two applicants:

Applicant A: No negative bureau records. Score: 750. Looks great on paper. Reality: earns R$ 3,000/month, spends R$ 2,800/month, has R$ 200 in savings, and is applying for a R$ 50,000 loan. This person will default.

Applicant B: One negative record from 2022 (a R$ 150 phone bill during a job transition). Score: 520. Reality: now earns R$ 12,000/month, spends R$ 6,000/month, has R$ 40,000 in savings, and is applying for a R$ 20,000 loan. This person will pay.

Bureau-only scoring approves Applicant A and rejects Applicant B. The bureau data is technically correct — A has no negatives, B has one. But the credit decision is wrong in both cases.

Our data shows that 30% of applicants rejected by bureau-only scoring are actually creditworthy when evaluated with full financial context. That's revenue left on the table, and customers underserved.

What Open Finance changes

Open Finance (Brazil's implementation of Open Banking, regulated by BACEN since 2021) allows consumers and businesses to share their financial data with third parties — with explicit consent, via standardized APIs.

The data available through Open Finance is transformative:

Bank statements (up to 12 months)

Real transaction history from the applicant's bank accounts. Not self-reported income. Not estimated expenses. Actual debits and credits, with merchant names, categories, and timestamps.

From bank statements, we extract:

• Net income: Actual salary deposits, freelance income, rental income
• Income stability: Does the same amount arrive every month, or is it volatile?
• Expense patterns: Fixed costs (rent, utilities) vs. discretionary spending
• Savings behavior: Does the applicant accumulate or deplete savings?
• Existing debt service: Loan payments, credit card payments, financing installments
• Cash flow timing: When does money come in vs. when does it go out?

Account balances

Current and historical balances across all accounts the applicant shares. This reveals:

• Liquidity: How much cash is available right now?
• Buffer: Does the applicant maintain a safety margin?
• Trends: Is the balance growing, stable, or declining?

Credit card statements

Transaction-level credit card data showing:

• Utilization ratio: How much of the limit is used?
• Payment behavior: Does the applicant pay in full or minimum?
• Revolving balance: Is the applicant carrying expensive debt?
• Spending categories: Where does the money go?

Existing loans and financing

All active credit products the applicant has across institutions:

• Total debt service: How much goes to debt payments monthly?
• Debt-to-income ratio: The real number, not the self-reported one
• Payment history: On-time, late, or missed — per product
• Remaining terms: How long until existing debts are paid off?

How LoanOS integrates Open Finance data

Our credit scoring engine, LoanOS, consumes Open Finance data alongside traditional bureau signals. The integration follows a pipeline architecture:

Step 1: Consent and data retrieval

When an applicant requests credit, they're prompted to share their Open Finance data. The consent flow follows BACEN's specifications:

1. Applicant selects which institutions to share data from

2. Applicant authenticates directly with each institution (redirect flow)

3. Institution issues a consent token to Revenu

4. Revenu retrieves data via standardized Open Finance APIs

5. Data is encrypted in transit and at rest

The entire consent flow takes 30-60 seconds. The applicant never shares their banking credentials with Revenu — authentication happens directly with their institution.

Step 2: Data normalization

Open Finance APIs return data in standardized formats (defined by BACEN), but each institution has quirks:

• Transaction descriptions vary ("PIX SENT" vs. "PIX - TRANSFER" vs. "PAGAMENTO PIX")
• Category codes may differ
• Date formats and timezone handling vary
• Some institutions include pending transactions, others don't

LoanOS normalizes all data into a canonical format before analysis. We maintain a mapping table of 2,000+ transaction description patterns to standardized categories.

Step 3: Feature extraction

From the normalized data, LoanOS extracts 147 features across 8 categories:

Income features (18):

• Monthly net income (average, median, trend)
• Income source count and diversification
• Income volatility (coefficient of variation)
• Salary date detection (for payment scheduling)
• Bonus/commission income identification

Expense features (22):

• Fixed vs. variable expense ratio
• Essential vs. discretionary spending
• Expense growth rate (month-over-month)
• Utility payment regularity
• Rent-to-income ratio

Cash flow features (19):

• Net cash flow (income minus expenses)
• Cash flow volatility
• Days-below-zero count
• Maximum cash deficit
• End-of-month balance trend

Savings features (12):

• Savings rate (savings / income)
• Emergency fund adequacy (months of expenses covered)
• Savings trend (accumulating vs. depleting)
• Investment account presence and growth

Debt features (24):

• Total debt-to-income ratio
• Debt service coverage ratio
• Credit card utilization ratio
• Revolving balance percentage
• Number of active credit products
• Payment punctuality score

Behavioral features (28):

• Gambling transaction frequency
• Overdraft usage frequency
• Loan-to-pay-loan patterns
• Account balance before salary (buffer behavior)
• Spending acceleration (increasing spending trend)
• Peer-to-peer transfer patterns

Stability features (14):

• Account age
• Primary bank relationship duration
• Address stability (based on utility payments)
• Employment stability (based on salary patterns)

Risk signals (10):

• Payday loan presence
• Cryptocurrency exchange transactions
• Multiple loan applications (detected via balance patterns)
• Sudden large deposits (potential fraud signal)

Step 4: Scoring model

LoanOS runs a gradient-boosted ensemble model that combines Open Finance features with traditional bureau data. The model outputs:

• Credit score (0-1000): Probability of default within 12 months
• Recommended limit: Maximum credit amount based on debt service capacity
• Recommended rate: Risk-adjusted interest rate
• Confidence level: How confident the model is (based on data completeness)
• Risk factors: Top 5 factors driving the score (for explainability)

The model is retrained monthly on new performance data. Every credit decision is tracked — approved, rejected, paid on time, defaulted — and fed back into the training pipeline.

Step 5: Decision engine

The scoring model output feeds into a configurable decision engine:

• Auto-approve: Score > 700 AND debt-to-income < 40% AND no active defaults
• Manual review: Score 500-700 OR unusual risk signals
• Auto-reject: Score < 500 OR active defaults > R$ 10,000
• Counter-offer: Approved but at lower amount or higher rate

Decision rules are configurable per product, per risk appetite, and per regulatory requirement.

The impact: bureau-only vs. Open Finance-enriched scoring

We ran a 6-month A/B test comparing bureau-only scoring against Open Finance-enriched scoring on the same applicant pool:

Approval rate

• Bureau-only: 52% approval rate
• Open Finance-enriched: 68% approval rate
• +16 percentage points — 31% more applicants approved

Default rate

• Bureau-only: 4.2% default rate at 12 months
• Open Finance-enriched: 3.1% default rate at 12 months
• -1.1 percentage points — 26% fewer defaults despite approving more

How is this possible?

More approvals AND fewer defaults seems contradictory. It's not. Bureau-only scoring is a blunt instrument — it rejects many creditworthy people (false negatives) while approving some non-creditworthy people (false positives). Open Finance data reduces both error types simultaneously:

• Fewer false negatives: Applicants with old/small negative records but strong current financials get approved
• Fewer false positives: Applicants with clean bureau records but poor cash flow patterns get flagged

Revenue impact

For a lending operation processing 10,000 applications per month:

• 1,600 additional approvals per month (at same or better risk)
• Average ticket: R$ 8,000
• Additional monthly origination: R$ 12.8 million
• With 3.1% default rate vs. 4.2%, the net portfolio quality is better

Privacy and consent: doing it right

Open Finance data is the most sensitive financial information a customer can share. We treat it accordingly:

Consent management

• Consent is granular: the applicant chooses which institutions, which data types, and for how long
• Consent is revocable: the applicant can revoke access at any time via the institution's app
• Consent has expiry: maximum 12 months, after which re-consent is required
• We never store raw Open Finance data longer than the consent period

Data minimization

We extract features from raw data, then discard the raw data. The scoring model works on features (e.g., "income stability score: 0.87"), not on raw transactions (e.g., "PIX received R$ 5,000 from Company X on March 5th").

This means:

• A data breach would expose feature vectors, not bank statements
• We can't reconstruct the applicant's transaction history from stored data
• Regulatory requests for data deletion are straightforward

Audit trail

Every data access is logged:

• When data was retrieved
• Which APIs were called
• Which features were extracted
• How the score was calculated
• What decision was made

This trail satisfies BACEN's Open Finance audit requirements and LGPD's transparency obligations.

Applicants without Open Finance: graceful degradation

Not every applicant will share Open Finance data. Some don't have a participating institution. Some don't trust the process. Some don't have a smartphone.

LoanOS handles this gracefully:

• With Open Finance data: Full 147-feature model, highest accuracy
• Without Open Finance data: Bureau-only model with 23 features, lower accuracy but still functional
• Partial data: If the applicant shares data from one institution but not others, the model uses what's available and adjusts confidence levels accordingly

The system never requires Open Finance data. It always improves with it.

The numbers from production

After 12 months of Open Finance-enriched scoring:

• 147 features extracted from Open Finance data
• 68% approval rate (vs. 52% bureau-only)
• 3.1% default rate (vs. 4.2% bureau-only)
• 30% of previously rejected applicants now approved with good performance
• < 2 seconds from data retrieval to score calculation
• R$ 153 million in additional origination volume (applicants who would have been rejected)
• Zero data breaches — feature extraction, not raw data storage
• 89% consent rate — when applicants understand the benefit, most opt in

Why this matters

The credit market in Brazil has 70 million adults who are "invisible" to traditional bureaus — they have no credit history, no score, and no way to prove their creditworthiness. Open Finance changes this by letting people prove their financial health with real data, not just the absence of negative records.

For lenders, Open Finance is a competitive advantage: approve more, lose less, and serve customers that competitors can't reach.

For applicants, Open Finance is financial inclusion: access to credit based on who you are today, not what happened years ago.

We built this integration because we believe credit decisions should be based on the best available data, not on legacy systems that were designed before smartphones existed. Open Finance is that data. And it changes everything.