FR
Every project in the digital banking market begins with a solution capability check. A concept that helps financial companies find the best solution for a specific use case while cooperating with the data enrichment provider that is most suitable for their needs. This initial exploration, known as Proof of Concept (PoC), is a cornerstone for any successful and enduring business. Let's learn more about all the vital aspects of the perfect PoC that sets the right expectations for the partnership.
Regardless of the product, understanding its potential is crucial. In digital banking, it's essential to see how your data can work for you and how to present it to users effectively. It doesn't matter how good the features or analytical models are if the core use case data does not meet the quality requirements. In other words, data is king.
To determine whether the enrichment provider gets the highest quality data, a Proof of Concept is created. This PoC aims to answer the most critical questions: Can it offer sufficient data coverage for the bank’s needs? Is the accuracy high enough, with a low error rate?
Specify the goal the PoC needs to achieve and the use case it's intended for. Determine the criteria and expectations for this assessment. Is the PoC focused solely on bank card transactions, or does it include regular bank account transfers and open banking data? The type and amount of data to enrich depend on this decision. When selecting data for your PoC, it’s essential to use a random and representative sample without filtering or deduplication. This approach provides a realistic benchmark for results, helping to avoid inflated expectations.
Additionally, providing all vendors with an identical data sample promotes fairness, making it easier to compare outcomes accurately. We recommend selecting a substantial sample size - such as one to two days’ worth of transactional data (at least one million transactions) - to avoid artificial enhancement and ensure the PoC results mirror real-world conditions.
As mentioned above, you need a sample that accurately represents real data. This means:
Additionally, provide correct input parameters in a correct format.
They differ for card and bank transactions, so it's crucial to provide as many parameters as possible. Key parameters for data enrichment include:
To learn what input data is required, and its ideal structure used to enrich the card payment data – refer to this link.
The PoC length needs a proper connection to the goals and resources the company wants to invest in during the testing period. To maintain fairness, all participating vendors should have identical timelines, with clear start and submission dates communicated well in advance. Additionally, setting a relatively short duration for the PoC, such as two to three days, can reduce the likelihood of manual data boosting, ensuring a true reflection of each vendor’s capabilities.
To unlock the full potential of each solution, supply vendors with all possible input parameters for the PoC. This includes sharing a structured data sample in advance for vendor feedback, allowing each provider to prepare effectively. Also, consider that transaction types - like card transactions versus account-to-account (A2A) transfers - require different data input parameters. Accounting for these variations ensures a comprehensive test of each vendor’s solution.
To obtain the most specific and helpful results, address the three crucial aspects of data quality: Coverage, Accuracy, and Information richness. The best approach is to compare data samples from different vendors, take into account approximately 100 transactions and identify differences in the provided information. Subsequently, evaluate the accuracy and richness of data from each provider. For more information, read our article about why data quality matters.
Key factors to evaluate include:
Large PoC are usually project-managed with significant resources invested, using large data sample and longer time frame to complete (usually 1-3 months).
Typical goals: Test real-live coverage, data accuracy and data richness (e.g., on Friends and Family).
Advantages: Realistically set expectations while knowing what the solution is capable of delivering. Avoiding buying a “pig in a poke” which is not possible with a smaller POC due to its limitations.
Disadvantages: Very time-consuming, typically not free and requires internal resources. Rarely possible to test multiple vendors at the same time.
Simple sample sharing with duration of 1-3 weeks, minimal effort on the bank's side.
Typical goals: Direct Comparison of multiple solutions (including internal). Data richness insight (e.g. categorization granularity, GPS accuracy)
Advantages - Possibility of partially testing data accuracy and richness. Relatively short time frame and low costs. Manual sample boost witch high impact on results.
Disadvantages: Not possible to test real coverage, the sample is not representative of typical operations.
The journey from exploration to market-ready solutions is not simple, but a well-built PoC serves as your compass, helping you understand the capabilities of different solutions. Picking the right PoC for your needs is a crucial step for achieving the expected results and avoiding mistakes that can occur in the process. Such mistakes include a lack of alignment with your data enrichment provider, insufficient specific data, or a simple lack of time due to an incorrect PoC model choice. Your time invested in a well thought out Proof of Concept today is the cornerstone for tomorrow's success story.
.webp)
Michal Maliarov
Senior insider
