Context
BBVA wanted to unlock financing for small and medium-sized enterprises (SMEs) that had no traditional credit history but demonstrated financial health through their transaction patterns. Traditional credit scoring relied on corporate credit bureaus which didn’t capture the full picture — seasonal businesses, new ventures, and informal arrangements between businesses didn’t register. The insight was simple but powerful: analyze real transaction data directly. If an SME’s bank account showed consistent income, manageable expenses, and healthy cash flow — especially with support from business partners or investors — it deserved financing. Trust·u was conceived as a fintech product inside the bank, bridging the gap between data availability and alternative credit decision-making.
Constraints
Bank-grade security and compliance: storing and processing live banking credentials required encryption at rest, strict access controls, and audit trails for regulatory scrutiny. Open Banking regulations required explicit consent and transparent data usage. The scoring algorithm involved cross-functional governance: risk teams, compliance, and finance all had veto power on the methodology. Third-party integration for bank scraping introduced latency and reliability dependencies. The team had to support multiple bank integration methods as APIs became available. Real-time scoring had to respect transaction lag times — recent deposits might not be confirmed, so the algorithm had to weight historical data more heavily. Fraud detection had to run alongside scoring to flag suspicious transaction patterns.
Decisions
Treat the transaction data pipeline as the critical path: source of truth for all downstream scoring. Build a layered architecture where the frontend (Angular) handled UX/authentication, the backend (Node.js/Express) orchestrated data flow and API contracts, and the Python scoring engine was isolated as a separate service that could evolve independently. Separate authentication from data access: users logged in with their BBVA credentials, but the platform requested explicit permission to access transaction data via a third-party aggregation service (not by storing credentials directly). Make scoring transparent: return not just a final score but the component scores (income stability, expense management, social proof from transfers) so users understood why they got a particular decision. Implement scoring versioning: as risk teams refined the algorithm, keep historical versions so decisions remain auditable.
Implementation
Frontend (Angular) — credential consent flow, user dashboard showing their score components, application workflow for loan requests. Backend (Node.js/Express) — API layer that orchestrates: user authentication against BBVA systems, permission management for transaction access, queuing jobs for the scoring service, caching results. Data Pipeline — transactions fetched from the third-party aggregator, normalized into a common schema, deduplicated and validated. Scoring Service (Python) — multi-stage algorithm that computed: (1) income stability by analyzing deposit patterns over time, (2) expense ratios by categorizing outflows, (3) social proof factor if business partners or family transferred money, (4) risk signals like sudden balance drops or circular transactions. The final score was a weighted combination of these components. Each score request logged the algorithm version, input data snapshot, and decision reasoning. Fraud Detection — ran in parallel with scoring, flagging patterns like rapid account drains or round-tripping behavior. Auditability — every score tied to a specific algorithm version and immutable data snapshot, so a decision could be reproduced or challenged months later.
Outcome
The platform successfully scored over 50,000 SMEs in its first year of operation. Loan disbursement decisions using Trust·u scores showed strong performance: default rates on Trust·u-backed loans were competitive with traditional scoring despite serving a riskier population. The transparency of component scores improved user trust — applicants understood why they were approved or declined, reducing support friction. The multi-department algorithm governance model worked better than expected: making scoring rules explicit and versionable forced risk and compliance to articulate their assumptions, catching edge cases that would have been implicit in a black-box model. The transaction-first approach revealed patterns traditional credit scoring missed: seasonal businesses, multi-owner structures, and cross-border cash flows all became visible and rateable.
Outcome metrics
- Scale
- Scored 50,000+ SMEs; backed thousands of loan disbursements
Tradeoffs
We chose third-party transaction aggregation over building direct integrations with every bank. Direct connections would have been faster and more reliable, but the aggregator abstracted away the complexity of supporting every banking API variant. The cost was latency (transactions 24-48 hours delayed) and dependency on a third party, but the operational simplicity paid off as regulations evolved and new banks had to be added.
We also chose transparent component scoring over a black-box final score. Simpler models exist that would have been faster to compute and harder for risk teams to second-guess, but the component breakdown was what made the product trustworthy — users and regulators could see the reasoning, not just the number.
What I learned
Transaction data is messier than credit bureaus. Transfers between accounts look like income, round-tripping happens, and categorization is ambiguous. We built extensive validation and flagging rather than trying to make the data pristine. The messiness is also the signal — suspicious patterns should be flagged, not normalized away.
The other lesson: algorithm governance at scale requires versioning, not just process. We tried to manage scoring rule changes through spreadsheets and meetings initially, and lost track of what was live vs. what was testing. Once we made every algorithm a versioned artifact with deployment logs, reproducibility and auditability became automatic.
What I would do differently
I’d invest in real-time transaction feeds earlier. The 24-48 hour lag in aggregated data was a constant friction point — users expected their recent deposits to reflect immediately in their score. When bank APIs matured and offered webhooks, we retrofitted support, but building for real-time from the start would have simplified the pipeline.
I’d also push back harder on committee-based algorithm governance initially. The transparency was valuable, but the process became a bottleneck for iteration. A better model would have been: propose changes with simulations, test on historical data, deploy behind a feature flag, monitor live performance, and commit/rollback based on metrics — rather than requiring committee approval before any change.
Future evolution
The next phases were (1) incorporating alternative data sources like utility bills and supplier payment records to score businesses with thin transaction histories, (2) integrating with the loan underwriting system so approved applicants could move directly to disbursement without manual handoff, and (3) real-time scoring on deposits and withdrawals so the platform could provide live feedback to users about actions that improve or hurt their score.
Principles applied
- Make the data pipeline the critical path — everything else is secondary
- Transparent algorithms over black boxes; component scores over final numbers
- Versioning and auditability as requirements, not nice-to-haves
- Third-party abstraction over direct integration complexity
- Transaction patterns reveal what credit bureaus miss
This project was part of BBVA’s broader fintech expansion. It informed later work on embedded lending and API-first banking for partners — the infrastructure and thinking around transaction analysis, scoring, and regulatory compliance became a foundation for multiple products.