Discuss your hiring requirements. Directly with a Partner.Talk to a Partner

+91 70424 03609

Hiring a Head of FinOps and Settlements

The function nobody budgets for until an auditor asks a question nobody can answer.

TL;DR

Head of FinOps and Settlements owns the machinery that proves a fintech's money is where it says it is: settlement across every rail and partner, reconciliation of internal records against banks, schemes, aggregators and partners, the investigation and clearing of breaks, merchant and customer payouts, refunds and chargebacks, and the controls the auditor will test.

It is the most reliably under-hired senior function in Indian fintech. The work is invisible when it is done well and existential when it is not, which means it rarely wins the budget argument until the month a reconciliation gap appears in a board pack.

Key points

  • The role sits between finance, engineering and operations and reports in different places depending on which problem the company has.
  • The measurable core is break rate, ageing of unresolved breaks, settlement timeliness and manual intervention volume.
  • Most Indian fintechs discover they need the role after an audit, a partner dispute or a funding diligence, which is the worst possible time to hire.
  • The scarce candidate is one who has built a reconciliation capability, not one who has operated someone else's.

Jump to FAQs

What the role owns

Settlement across rails and partners. Knowing, every day, what settled, what did not, and why. Each rail has its own file formats, timings and failure modes, and each partner has its own version of the truth.

Reconciliation. Matching internal ledger records against bank statements, scheme settlement files, aggregator reports and partner statements. The engineering behind this is described in reconciliation and breaks; the operating discipline is what this role owns.

Break management. Identifying, categorising, investigating and resolving mismatches, with ageing discipline so that unresolved items are visible rather than accumulating quietly. The ageing report is the honest measure of whether the function is working.

Payouts and disbursals. Merchant settlement, vendor payouts, customer refunds, and the controls around all of them.

Chargebacks and disputes. Operationally heavy, deadline-driven, and in India increasingly conduct-sensitive.

Nodal, escrow and pool account discipline. Where the company holds funds on a licence or under a partner's licence, the account rules are supervised. Movements, balances and permitted uses are prescribed, and breaches are regulatory findings rather than internal issues.

Controls, audit and evidence. Being the person who can produce, on request, the complete trail for any transaction. This is the capability a funding diligence or a regulatory inspection actually tests.

Month-end close support. The finance team's close depends on this function, and a close that slips is usually a reconciliation problem wearing a finance badge.

Why it is under-hired

Four reasons, and recognising them is useful when making the internal case.

It has no revenue number. The function prevents loss rather than creating gain, so it loses budget arguments to anything with a growth story attached.

It appears to be covered. There is usually a finance analyst doing reconciliation in spreadsheets and an engineer who built a matching script. Both are competent; neither owns the capability, and the gap is invisible until volume exposes it.

The failure is slow. Break ageing degrades over months. By the time anyone notices, there is a backlog that takes a quarter to clear and an audit question that cannot be answered quickly.

It falls between functions. Finance thinks it is operations, operations thinks it is engineering, engineering thinks it is finance. In companies where nobody owns it, all three are partly right, which is exactly why it fails.

The trigger that usually forces the hire is external: an auditor's qualification, a partner dispute over settlement, a funding diligence that asks for a reconciliation summary, or a regulatory inspection. All of these are worse moments to start a search than the quarter before.

Which backgrounds transfer

Background Transfers Watch for
FinOps or settlement leadership at a payment aggregator or large fintech Strongly. The closest match Small pool. Verify whether they built the capability or inherited it
Bank operations: payments, clearing, settlement Strongly Deep process discipline; assess comfort with building tooling rather than using it
Broking or exchange back office operations Well Settlement rigour is excellent. Payments-specific rails need learning
Finance controllership with reconciliation ownership Well Strong on controls, usually lighter on rail-level operational detail
Payment operations management, stepping up Often the best value Assess whether they can design a control environment, not only run one
Big Four process or internal audit Partially Knows what good looks like, rarely has run it under volume

The most useful distinction in interviews is between a candidate who has built a reconciliation capability, choosing or building the tooling, defining the matching rules, setting up the break workflow and the ageing discipline, and a candidate who has operated one someone else built. Both are valuable; only the first can fix a company that does not have one.

How to assess

Ask for their break rate and ageing. "What percentage of transactions broke, and what was the oldest unresolved item when you left?" Candidates who have owned this answer precisely, including the seasonal and partner-specific variation. Anyone who does not have numbers has not owned the function.

Ask about the worst break they resolved. Amount, how long it took, what the root cause turned out to be, what changed afterwards. The good answers almost always end in a systems or process change rather than in a correction.

Test the audit scenario. "An auditor picks one transaction from fourteen months ago and asks for the full trail. Walk me through it." This is the capability, stated plainly.

Probe the automation judgement. "Where would you automate first, and what would you deliberately keep manual?" Strong candidates have a view about which exceptions should stay human, and why. Weak candidates want to automate everything.

Check the partner conversation. "A partner's settlement file disagrees with yours by ₹18 lakh. What happens next?" The answer reveals whether they can hold a commercial conversation as well as an operational one.

Assess the engineering relationship. This role succeeds or fails on whether it can get engineering time. Ask how they have secured it before.

The search reality

Scope drives the title and the level. At one end this is a manager running a small team against a vendor platform. At the other it is a leader of forty people, owning the control environment for a licensed entity, reporting to the CFO. Establish which before going to market, because the compensation bands barely overlap.

Reporting line signals the problem being solved. Into the CFO when the driver is controls and audit, into the COO when it is operational scale, into the Head of Payments when it is rail-level settlement performance. All three work. What does not work is leaving it ambiguous, because the role then has responsibility without the authority to get engineering capacity.

The pool is concentrated and quiet. Payment aggregators, the large consumer fintechs, broking platforms and bank operations. Few of these people are in the market, and almost none are applying to job postings, which makes this a mapped and approached search. Our method is in how we search.

Hire before the audit, not after. The single most useful observation we can offer. A company that hires this role while things are working gets a candidate who builds; one that hires after a finding gets a candidate who inherits a backlog and spends their first two quarters on remediation rather than design.

Pair it with the systems investment. A strong FinOps leader with no engineering support will not fix a reconciliation problem, because most of the fix is in the systems described in ledger architecture and reconciliation. Companies that hire the person and withhold the capacity get neither.

Common questions

What does a Head of FinOps do in a fintech?

Owns settlement, reconciliation, break management, payouts, refunds and chargebacks, nodal and escrow account discipline, and the controls and evidence that auditors and regulators test. In practice the role is responsible for being able to prove, for any transaction, what happened and where the money went, and for keeping the gap between internal records and external parties small and ageing-controlled.

What metrics should a Head of FinOps own?

Break rate by rail and partner, ageing of unresolved breaks with a defined escalation threshold, settlement timeliness against expected cycles, manual intervention volume as a share of transactions, chargeback and dispute resolution within deadline, and the time required to produce a full transaction trail on request. A candidate who cannot discuss their own numbers on these has not held the accountability.

Should FinOps report to finance, operations or payments?

It depends on the problem. Into the CFO where the driver is controls, audit readiness and close discipline; into the COO where it is operational scale and headcount; into the Head of Payments where it is rail-level settlement performance. Each works. The failure mode is an unclear line, which leaves the role accountable for break resolution without the authority to secure engineering time to fix the causes.

Why do fintechs hire this role too late?

Because the function has no revenue number, appears to be covered by a finance analyst and an engineer's script, and fails slowly rather than visibly. The usual trigger is external: an audit qualification, a partner settlement dispute, a funding diligence or a regulatory inspection. All of those are worse starting points than hiring in a quarter when nothing is broken, because the new leader then spends their first two quarters clearing a backlog instead of designing the capability.

Is FinOps the same as payment operations?

Overlapping but not identical. Payment operations usually means running the day-to-day of payment processing: monitoring, failures, retries, support escalations. FinOps extends that to the money-truth side: settlement, reconciliation, breaks, payouts and the control environment that evidences it. In smaller companies one team does both; as volume grows, the control and settlement responsibilities usually separate out, and that separation is typically the point at which this role is created.