Financial data analysis
Finance data is usually spread across a core system, a payments platform, spreadsheets and a CRM. We bring it into one model with clear definitions, so revenue, margin and exposure mean the same thing in every report. Analysis then answers specific questions: which customers are likely to leave, where margin is leaking, which accounts behave unlike their peers.
Our founder, Kunal Miind, consults to financial institutions on AI, including financial modelling and conversational analysis. He has built fraud detection and machine learning models for clients including Philip Morris, Queensland Health and Australian Government agencies.
Anomaly and fraud detection
Fraud is rare, and it changes once it is caught. That shapes how we build detection:
- Layered methods. Rules catch known patterns cheaply. Unsupervised anomaly scores, such as isolation forests, flag new behaviour that no rule describes. Supervised models, often gradient-boosted trees, learn from confirmed cases. Each layer covers gaps in the others.
- Features that carry signal. Velocity (how many events in a time window), deviation from the customer's own history, device and network attributes, and links between accounts that share details.
- Thresholds set by cost. A missed fraud and a false alarm cost different amounts. We set thresholds from those costs and the review team's capacity, and report precision and recall at the chosen operating point rather than a single accuracy figure.
- Feedback loops. Analyst decisions flow back as labels, and we watch for drift as fraud patterns adapt.
Conversational analysis
Calls, chats and emails hold signals that never reach a ledger: complaints, hardship, possible misconduct and the reasons customers leave. We transcribe recorded calls with speech-to-text, then classify and summarise conversations so a compliance or customer team reviews the ones that matter instead of a random sample. Personal details are redacted before analysis, models run in your environment where required, and each flag links back to the recording and the passage that triggered it. Scores are checked against conversations your reviewers have already assessed, so the team can see how often a flag is right.
Forecasting with error ranges
A forecast without an error range invites false confidence. We produce probabilistic forecasts for cash flow, demand, collections or exposure, with prediction intervals that show the likely spread. Methods range from classical time series models to gradient boosting with calendar, pricing and economic features. We backtest on rolling windows, so the reported error matches how the forecast will be used each week or month.
Data pipelines you can check
Models are only as reliable as the data feeding them. We build pipelines that:
- Load raw data unchanged first, then transform it in versioned, tested steps.
- Check data contracts at each boundary: expected columns, types, ranges and row counts.
- Reconcile totals back to the source system on every run, and stop loudly when they do not match.
- Record lineage, so any number in a report can be traced to the rows that produced it.
Security and auditability
Financial systems need controls an auditor can test. We apply least-privilege access, encryption in transit and at rest, and logs of who accessed which data and when. Each model version is stored with its training data snapshot, code version and test results. Each score it produces comes with the main factors behind it, using explanation methods such as SHAP values.
For APRA-regulated entities, prudential standards CPS 234 (information security) and CPS 230 (operational risk management) shape how data platforms and models are hosted, monitored and supplied. We design with those requirements in view and document the controls so your risk team can assess them.
Questions
Can you work inside our environment?
Yes. We can build and run pipelines and models inside your cloud account or data platform, so the data stays under your control.
How do you explain model decisions to auditors?
Each score comes with the main factors behind it, and each model version is stored with its data snapshot, code and test results.
Will a model replace our fraud rules?
Usually not. Models sit alongside rules, catching what the rules miss and reducing false alarms on what they already catch.