SVP – Digital Platforms — Consumer-Finance Book

The mandate

A consumer-finance group has acquired a complementary lender and now operates two origination stacks, two servicing cores and several duplicated data and partner interfaces. Customers feel the seams when an application changes channel, a payment arrangement reaches collections or an existing borrower seeks another product. Technology incidents are manageable individually, but accumulated workarounds slow releases and make ownership difficult to establish. The group is creating an SVP Digital Platforms role to make one deliberate architecture from the combined estate.

Around 350 engineers, product technologists, service managers and partners fall within scope. The underlying book and technology-investment perimeter is approximately ₹6,300 crore. The role owns platform architecture, engineering delivery, reliability, integration sequencing, technical risk and the major vendor relationships supporting origination, account management and collections. Business product ownership and independent risk approval remain outside the post, demanding partnership rather than control by organisational reach.

A rapid migration to either legacy stack would be superficially decisive and potentially destructive. Each platform contains capabilities, contractual constraints and hidden operational knowledge that require evidence. The SVP must establish which domains converge, which are replaced, and where an interim façade is justified. Decisions must consider customer continuity, model and data lineage, regulatory records, partner certification and recoverability—not engineering preference alone.

Why this seat is open

The acquisition integration created a leadership gap between business CIOs and programme governance. The board classified the new position as urgent after cross-platform dependencies began to delay customer and control changes. It wants a permanent technology owner before committing the next tranche of migration capital. Existing leaders will continue to run daily services; the SVP will hold the combined destination and sequencing.

What you will own

• Produce a domain architecture and disposition for both estates: retain, converge, replace or retire, with cost, risk, dependency and customer reasoning.
• Sequence migration by customer journey and data integrity rather than by application count.
• Establish engineering ownership from code through production, including service objectives, incident learning, vulnerability remediation and recoverability.
• Protect credit-model inputs, consent, account records and collections evidence as data moves between platforms.
• Rationalise vendors and licences, addressing exit rights, concentration, skills transfer and service continuity before commercial renewal dates.
• Introduce release governance proportionate to risk, enabling low-risk change to move quickly while controlling migrations and financial calculations rigorously.
• Build one engineering leadership team from both organisations and reduce reliance on external resources in domains containing critical knowledge.
• Explain technical debt and architectural choices to the board in terms of customer, resilience, delivery and economic consequence.

The first 12 months

The first eight weeks should establish service and dependency truth. Review significant incidents, failed releases, reconciliation breaks, vendor obligations and undocumented interfaces. Trace three difficult journeys across both estates and identify where manual intervention protects customers from platform gaps. No irreversible convergence decision should precede this work.

By day 120, seek approval for the domain roadmap, migration principles, capital profile and retirement economics. Name the services whose reliability must improve before they absorb more volume. Assign accountable engineering owners and confirm how historic records, consent and model lineage will be preserved and tested.

Over the following six months, deliver two end-to-end journey migrations, not isolated component moves. Reduce high-severity technical debt in the chosen domains, renegotiate priority vendors and exercise recovery for the combined customer path. Track customer completion and operational intervention alongside delivery velocity.

At year end, customer journeys migrated under the new model should show at least 25% fewer manual interventions and 20% faster completion. Severe incidents attributable to cross-platform failure should fall by 40%; recovery objectives for critical combined services should be proven; 90% of tier-one services should have named ownership and current runbooks; and the board-approved retirement plan should remove at least 15% of duplicated annual technology cost.

What the board will measure

• Journey outcomes and service reliability after migration, not applications moved in isolation.
• Reduction in cross-platform incidents, manual bridges and inconsistent customer or account data.
• Capital consumed relative to retired run cost and delivery of contractual vendor exits.
• Recovery evidence for critical origination, servicing, payment and collections paths.
• Control of model, consent and regulated-record lineage throughout data transition.
• Integration and retention of engineering talent from both legacy organisations.

The person

You have 18–22 years in financial-services technology and have led a post-acquisition platform convergence or equally complex core modernisation. Your remit has included at least 350 employees and partners and a business, book or technology perimeter of ₹3,700 crore or more. You remain technically credible while leading through engineering managers and architects.

Your examples show selective judgement. You can explain why one system was retained despite executive pressure, why another was retired, how data evidence was protected and what customer or run-cost result followed. Experience limited to greenfield digital channels will not substitute for changing a live, regulated estate.

You are fluent in reliability, secure engineering, vendor leverage and migration economics. You treat operations colleagues as sources of system knowledge rather than downstream recipients, and you can challenge both premature standardisation and endless architectural debate.

Compensation and terms

The anticipated fixed package is ₹2.2–3.0 crore plus performance variable, assessed against migration outcomes, reliability, cost retirement, risk and engineering-team health. This permanent appointment is onsite in Hyderabad. The organisation seeks an urgent hire but will agree a transition that protects the candidate’s current operational responsibilities.

Confidentiality

The acquisition parties, platforms and vendors are intentionally withheld. More detailed architecture will be discussed only after qualification, conflict review and a confidentiality undertaking. The numbers and circumstances are composite and should not be interpreted as a fingerprint for any particular company.