Tilores for lenders: avoiding duplicate finance applications.
TL;DR
- Identity resolution fits into a modern data stack as the layer that turns raw customer and application records in a warehouse or lakehouse into duplicate, unique, or related-entity context for operational systems.
- In the Banxware case, customer and loan application data stayed in Snowflake, Tilores connected to that warehouse, and Taktile queried Tilores via API so the risk workflow could retrieve duplicate and related-account signals in real time.
- Use a dedicated entity-resolution layer when exact-match warehouse checks are not enough for messy applicant details, related companies, connected-client risk, or high-volume manual review. Keep credit approval, compliance interpretation, and model decisions in the lender's governed risk process.
Table of Contents
- Short answer
- Next step with Tilores
- Decision guide
- Where identity resolution sits in a Snowflake lending stack
- Why duplicate finance applications are harder than exact matching
- How real-time retrieval supports credit risk workflows
- What to measure before replacing manual review
- Frequently Asked Questions
Short answer
Identity resolution sits between the data platform and the decisioning workflow. Snowflake or Databricks can centralize customer and application records, but the risk team still needs a resolved entity layer that can identify whether a new applicant is unique, a duplicate, or potentially related to existing customers before a decision is made.
This source article proves the pattern with Snowflake: Banxware stored customer and loan application data in Snowflake, connected Tilores to that data, and used a Taktile API integration to retrieve Tilores identity-resolution results inside the credit risk workflow. The same architectural question applies to lakehouse stacks, but the verified integration evidence in this article is Snowflake-specific.
Next step with Tilores
Use the next step that matches your evaluation stage.
Decision guide
| Question | Use Tilores when | Watch-outs |
|---|---|---|
| Is the warehouse enough on its own? | Snowflake holds the customer and application data, but the business needs reliable duplicate, unique, and related-account context before each risk decision. | SQL rules and exact matching can catch obvious duplicates. Messy applicant details and related companies need more careful entity-resolution logic. |
| Where should the identity result be consumed? | A credit risk platform, fraud workflow, or decision engine needs API-accessible resolved customer context while the original data remains governed in the data stack. | Keep data access, permissions, retention, and audit requirements explicit. Identity resolution supports the decision workflow; it does not replace risk governance. |
| Should the team build its own deduplication workflows? | Building an enterprise-level entity-resolution system would pull engineering time away from the core lending product or create a long-term maintenance burden. | A custom workflow can be reasonable for a small, stable, low-risk data set. Production fintech use cases need monitoring, thresholds, review paths, and false-positive control. |
| What risk signal should the workflow return? | The lender needs to know whether an applicant appears unique, duplicated, or potentially related to other customers before credit risk review continues. | Do not treat entity resolution as a legal or regulatory guarantee. It supplies match context that the lender's risk, compliance, and decisioning teams must interpret. |
Where identity resolution sits in a Snowflake lending stack
In a Snowflake-centered lending stack, the warehouse can remain the place where customer and loan application records are stored, while identity resolution acts as the operational layer that links records belonging to the same person, company, or related group.
The resolved context then needs to be available to the systems that make or support lending decisions. In the Banxware workflow, Taktile queried Tilores via API so the risk process could retrieve whether a customer was unique, duplicated, or potentially related to another Banxware customer.
Why duplicate finance applications are harder than exact matching
Duplicate finance applications often contain small differences in applicant details. Names, company records, addresses, and contact fields may not line up cleanly, especially when an applicant has applied before through a marketplace or merchant partner.
That makes simple exact matching a weak control for risk teams. The useful signal is not only whether two rows are identical, but whether multiple records point to the same applicant, the same business, or accounts that may be related enough to require review.
How real-time retrieval supports credit risk workflows
A lender does not need identity resolution only as an offline data-quality report. The risk workflow needs current resolved customer context while an application is being assessed, so duplicate and related-account signals can be considered before the decision path continues.
In the source case, Tilores connected to Banxware's Snowflake data and Taktile built the API integration that brought Tilores data into Banxware's credit risk workflow. That is the practical fit: the warehouse stores the data, Tilores resolves identity context, and the decision platform retrieves the result.
What to measure before replacing manual review
The source case reports nearly 100% reduction in manual review of loan applications, one day to configure the Snowflake integration, one week for the Taktile API integration, and a significant increase in detection of non-obvious duplicates and related accounts over the manual process.
Those metrics should be read as Banxware case-study evidence, not as a universal benchmark. A lender evaluating the same pattern should track review volume, duplicate detection, related-account detection, false positives, false negatives, integration effort, and how match evidence is reviewed by the risk team.
Banxware is an embedded Lending as a Service Provider, built to democratize access to capital. Banxware abstracts away the complexity of building lending in-house by securing a credit line, handling KYC, AML & credit decisions, and managing payouts & repayments. Through their solution, platforms and payment providers, such as Fiserv, Forto and Lieferando can offer fully digital business loans to their sellers.
See also the case study on Banxware’s website.
Risk Decision Challenges
Banxware must make individual credit risk decisions on each loan application from small businesses as they apply for finance via their marketplaces and merchant partners.
All of Banxware’s customer and loan application-related data is stored in Snowflake, the cloud based data warehouse solution. Before making a credit risk decision about whether to approve a loan application, Banxware’s risk team first of all needs to check whether the applicant has previously applied for finance, or is already a Banxware customer.
This process was a headache for Banxware’s risk team, as small differences in loan applicants’ details made it difficult to find duplicate applications, which could signify potential fraud cases. In addition, Banxware needs to comply with European Banking Authority (EBA) “Guidelines on Connected Clients” to avoid credit concentration risk by lending to different companies that are actually related to each other.
As loan volumes increased, Banxware needed to find a more scalable solution.
Partnering with Tilores
“Having built highly scalable lending platforms before, I know how critical good data is for credit risk decisions and fraud prevention, so I was delighted to partner with Tilores. Their identity resolution technology gives us exactly what we need to detect in real-time whether loan applicants are duplicates, or truly unique customers.” - Nicolas Kipp, Co-founder and Chief Risk Officer at Banxware.
Banxware considered building their own workflows to detect duplicate data in their data warehouse, but realised that to build an enterprise-level entity resolution system would be expensive and divert valuable engineering resources from working on their core lending product.
With Tilores, they found a Snowflake Technology Partner that already had a bespoke integration that makes it quick and easy to connect to Snowflake. Banxware’s risk team was able to connect Tilores to their Snowflake data warehouse, without having to involve their engineering team.
Another of Banxware’s technology partners, Taktile, the credit risk decision platform, built an integration with Tilores via the API so that customer data in Tilores is queried in real-time via Taktile to verify whether a customer is unique, a duplicate or potentially related to other Banxware customers.
With Tilores’ entity resolution technology at their side, Banxware now has the advanced data infrastructure to complement their credit risk decision models that will scale with them as their business grows on their journey to becoming Europe’s number one embedded finance provider.
Visit Banxware
Key Metrics
- ✅ Nearly 100% reduction in manual review of loan applications.
- ✅ One day to configure Tilores’ integration with Banxware’s Snowflake data warehouse.
- ✅ One week for Taktile to build an API integration and connect Tilroes’ data into Banxware’s credit risk division workflow.
- ✅ Significant increase in detection of non-obvious customer duplicates and related accounts over manual process.
Frequently Asked Questions
- How does identity resolution fit into a modern data stack with Snowflake or Databricks?
- Identity resolution sits between stored customer records and downstream operational workflows. The warehouse or lakehouse centralizes the data, while the identity-resolution layer links duplicate or related records and exposes current resolved customer context to decisioning systems.
- Can Snowflake deduplication alone detect duplicate finance applications?
- Snowflake can support deduplication logic, especially for exact or rule-based checks. A dedicated entity-resolution layer is a better fit when applicant details vary, matches are fuzzy, related companies matter, and the result needs to be retrieved by a live risk workflow.
- Why did Banxware use Tilores with Snowflake?
- Banxware stored customer and loan application data in Snowflake and needed a scalable way to detect duplicate applicants and potentially related customers before credit risk decisions. Tilores connected to the Snowflake data, and Taktile integrated with Tilores via API for the risk workflow.
- Does Tilores replace credit risk decisioning or compliance review?
- No. Tilores supplies identity-resolution context, such as whether an applicant appears unique, duplicated, or potentially related to another customer. Credit approval, regulatory interpretation, compliance controls, and final risk decisions remain the responsibility of the lender and its governed decisioning process.
Evaluate Tilores on your own data
Use the next step that matches your evaluation stage.
See what resolved entity data does for your business — and your AI.