-
Demo Pic
-
Demo Pic
-
Demo Pic
Inspiration
On the surface, everyday digital payments seem very fast, but the reality is that the banks, payment gateways, and apps involved in a transaction might still be in the process of verifying the success of that transaction. This causes a 'pending' notification to be seen by users for days, merchants have no idea if they have been paid, and support teams talk through Excel sheets which are not friendly and try to investigate the issue of the transactions. ReconX was born out of the difference between the front-end user experience of a seemingly flawless payment process and the back-end chaos of reconciliation, especially in emerging digital economies.
What it does
ReconX is a transaction reconciliation engine operating in real time that compares two transactional data sources (for this demo: Core Banking vs Payment Gateway) and automatically classifies each transaction. It identifies the exact matches, matches with different amounts, matches with different statuses, and transactions missing from either side and then displays them in an easy-to-understand dashboard from where operational teams can quickly find out the cause and location of the problem.
How I built it
I developed ReconX with Python within a virtual environment, using pandas to read from CSV/Excel files containing txn_id, timestamp, amount, and status for both systems. An outer join on txn_id gives a combined view, from which the program derives simple rules to identify each row as matched, mismatched, or missing, and create tables and summary statistics for each category.
Above this core engine layer, we built a Streamlit app that allows users to upload files or use sample data, press a single “Run Reconciliation” button, and immediately get KPIs, a Plotly bar chart of issue categories, and expandable tables of problematic transactions.
Challenges I ran into
Point scoping up the first challenge: a production‑grade reconciliation platform would require streaming ingestion (Kafka), very large data volumes, and complicated tolerance rules, whereas I only had the hackathon time. To cope with this, I purposely confined the MVP to batch files while figuring out the join logic and schema so that they could connect the streams later.
The second challenge was to create realistic demo data that clearly shows interesting mismatches and not confuse people, which involved fine-tuning a generator to produce just the right mix of amount and status discrepancies and missing transactions for both sides.
Accomplishments that we're proud of
One of our biggest accomplishments is that ReconX orchestrates a full end‑to‑end flow in a small, understandable codebase: from raw files to a visual dashboard that non‑engineers can use. In a very short time, we succeeded in going from an idea to an internal‑tool–style app that works and immediately exposes reconciliation issues and can actually be inserted into a bank or fintech’s operations workflow. Another thing we are proud of is the setting of the virtual environment and the requirements file that are very neatly done and thus make the project runnable on any laptop with a single streamlit run app.py command.
What I have learned
The takeaway for me was that transparent, simple rules applied to well‑constructed data can have a huge positive impact on people’s trust in financial systems, provided the results are presented clearly.
I also realized that showing a combined view of the two systems side by side makes it obvious how even small differences in amounts or statuses lead to user‑visible problems, and that providing clear explanations is crucial in regulated domains.
From a technology perspective, this project confirmed that Streamlit and pandas are powerful tools for rapid data‑product prototyping, and that the entire hackathon process becomes much smoother when you start by setting up a dedicated virtual environment.
What's next for ReconX – Real-Time Transaction Reconciliation Engine
In the near term, I want to connect ReconX to streaming sources such as Kafka topics instead of relying on static files, so mismatches can be detected almost immediately after a transaction is processed. I also plan to add tolerance rules and anomaly scoring (for example, flagging unusually frequent mismatches for a merchant or gateway), along with alerting integrations so ops teams receive notifications about high‑risk discrepancies and users can see timely status updates in real time.
Log in or sign up for Devpost to join the conversation.