.webp)
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.
Why is PoC so important?
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?
How to build a working PoC
Step 1: Pick a goal according to usecase and acceptance criteria
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.
Step 2: Choose the right data sample according to your goals
First, you need a sample that accurately represents real data. This means:
- No filtering (leaving out big merchants, transactions from some countries or e-commerce)
- No unique transactions or terminals. Data sample needs to be from a specific time period
- Data sample needs to be the right size (1-10k as a small sample, 100k and more as a big sample)
Additionally, provide correct input parameters. Additionaly, provide 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:
- Merchant ID: key parameter for determining the specific business branch
- Merchant description: key parameter for determining the merchant and specific branch
- MCC code: key parameter for categorizing merchants
- Country: key parameter for categorizing merchants and recognizing branches
To learn what input data is required, and its ideal structure used to enrich the card payment data – refer to this link.
Step 3: Define the length of the POC in advance
The PoC length needs a proper connection to the goals and resources the company wants to invest in during the testing period. Establish a specific timeline for all the steps. In case of multiple vendors, always establish identical conditions for each one for the most comparable results.
Step 4: Data enrichment and final evaluation
To obtain the most specific and helpful results, utilize as much variable data as possible, addressing 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.
How to approach PoC according to size
Large PoC (10k - 100k+)
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.
Small POC (1 - 2)
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.
Conclusion
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)
