From Mathematical Equations to Financial Modeling: My HackerRank Hackathon Experience

In the HackerRank Orchestrate hackathon, the task was to create a financial affordability decision engine called "Buy or Wait?". The system needed to determine whether a person should pay for something now, pay partially, use installments, wait until a later date, or not make the payment at all. Initially, the participant thought the problem was purely mathematical, but upon analyzing the dataset and problem statement, they realized it was a financial modeling problem.

The challenge involved deciding if a person could afford a purchase without dipping into their minimum safety balance, considering factors such as upcoming rent, pending debits, subscriptions, future salary, and other recurring expenses. The participant structured the system into separate stages. First, the system loaded financial profiles, events, requests, payment options, messages, images, and exchange rates.

Next, the engine built the user's financial state by converting foreign-currency transactions, reserving pending debits, ignoring failed, cancelled, and unrealized events, detecting recurring income and expenses, applying relevant evidence from messages and images, respecting protected spending categories, and using the user's payment preferences.

The engine then created a future balance projection for each event, adding income, expenses, and proposed payment plans to the projection. The lowest projected balance was used to determine the safe amount, considering both current and future balances. Identifying recurring expenses was challenging, as repeated transactions did not always indicate a recurring pattern.

The participant used historical transactions and checked factors such as the number of occurrences, gap between transaction dates, consistency in cadence, stability of amounts, description consistency, and outlier values to determine recurring expenses.

The participant explained that choosing a payment plan involved simulating different options, such as full payment today, full payment at a later date, partial payment, or installments. Each plan was tested through the same balance simulation, and if the balance fell below the user's minimum safety balance at any point, the plan was rejected. Spending changes were also considered, with the engine checking if certain expenses could be stopped or reduced based on user preferences.

Although the project involved AI, the participant decided to keep the decision deterministic to ensure reproducibility and auditability. The affordability decision involved critical factors such as money, dates, constraints, and safety limits, which needed to be reliable. The participant used AI for implementation assistance, unstructured evidence, and explanation generation but relied on deterministic Python logic for the final financial decision.

The participant learned that the dataset did not always follow a straightforward mathematical pattern, and decisions depended on factors like pending events, income timing, recurring expense forecasting, and same-day transaction ordering.