Senior Vice President GRC Platform Delivery — Banking Risk Workflow Coherence

The mandate

Five risk-domain teams in a banking technology platform are delivering GRC changes against incompatible workflow assumptions. A control issue can be closed in one domain while the associated risk assessment still treats remediation as incomplete; common labels can represent different business judgements. The new SVP will own delivery coherence across this portfolio, with MetricStream as the central GRC environment. Employment is open-ended. The opening twenty-four months will align approved risk concepts, workflow behaviour and release evidence without assuming that common technology automatically creates a common risk policy.

The work begins by distinguishing concepts that should be shared from differences that are justified by domain or legal entity. Risk owners determine appetite, methodology and control obligations; your teams translate those positions into traceable requirements and configured workflows. You will make unresolved definition conflicts visible before build decisions proceed. A platform should preserve the distinction between issue closure, control effectiveness and accepted residual risk rather than encourage users to treat a single completed task as proof that all three questions have been resolved.

Ninety functional, delivery and quality colleagues report through five domain leads. You own portfolio sequencing, delivery-resource allocation and the evidence standard for business acceptance. Platform engineering retains architecture and security authority, and approved risk owners sign off policy interpretations. The steering committee decides material scope and funding changes. You can reject a release lacking agreed end-to-end tests, but cannot accept risk for an entity or redefine a compliance obligation to eliminate an inconvenient workflow. Independent audit retains access to the reasoning and evidence behind delivered changes.

The first integrated release should demonstrate consistent behaviour across assessment, issue and remediation paths, including justified exceptions that remain visible. Subsequent cycles must prove that upgrades and local changes do not silently alter approved meanings or permissions. Mumbai is the leadership base, with scheduled international owner workshops and practical overlap hours. The enduring SVP seat includes building a functional-expert bench, managing demand and reviewing release quality; it is not a project title that expires once the first set of modules has been deployed.

What you will own

• Establish the cross-domain concept register with risk owners, recording approved definitions, justified local differences and unresolved conflicts before functional teams turn them into configured fields or workflow states.
• Decide delivery sequencing around shared assessment, issue and remediation dependencies, preventing one domain's release from changing another team's approved behaviour without a coordinated impact decision.
• Set end-to-end acceptance cases that distinguish task completion, issue closure and residual-risk acceptance, requiring authorised business owners to confirm the different outcomes rather than approve screens independently.
• Build requirements traceability from risk-owner decisions through configuration and tests, retaining the reasoning behind exceptions so later upgrades do not remove a necessary difference as apparent technical inconsistency.
• Allocate specialist delivery capacity across domain teams using dependency and change complexity, challenging plans that assume functional expertise can be substituted by additional generic project coordination.
• Review release and permission changes with engineering and quality leads, withholding delivery acceptance where an apparently minor adjustment can alter who may evidence, review or close a consequential risk record.
• Develop domain leaders through contested-requirement reviews, making them capable of surfacing policy questions early and resolving delivery choices without relying on the SVP to interpret every business disagreement.

Candidate qualifications

• Explain a GRC delivery decision where similar terminology concealed different risk or control meanings. Identify the business authorities you consulted, the functional design you changed and the test that demonstrated coherent behaviour. The evidence must show your contribution to the delivery outcome while clearly distinguishing it from risk appetite, methodology or policy decisions made by authorised owners.
• Bring 22–28 years in banking technology, GRC implementation or financial-services transformation, with VP or substantial programme leadership scope. Deep MetricStream functional experience is expected, supported by relevant certification or equivalent applied expertise across risk and compliance workflows. Show the portfolio scale you managed and functional specialists you developed rather than relying on the number of projects listed under your supervision.
• Demonstrate integrated testing and requirements traceability across assessment, issue and remediation processes. You must be able to challenge a release that passes module tests but fails a business outcome or introduces an inappropriate permission. Experience should include handling domain differences, upgrade impact and unresolved owner decisions without hiding them inside a technical backlog or accepting a convenient uniform design.
• Evidence senior collaboration with risk, audit, compliance and engineering stakeholders whose professional responsibilities remained independent. Describe how you sequenced scarce expertise, negotiated a contested release and protected decision records under timetable pressure. Sustained management of delivery capacity and quality must include clear delegated powers, explicit business acceptance and the judgement to escalate unresolved risk rather than trade it for an apparently favourable milestone.

Application

Applications for this mandate are received in one way only: through the India Board Terminal's application process. It is automated end to end. Your Executive Passport travels to the mandate holder in its confidential form, your answers to the three questions below are read before anything else in your file, and every stage that follows is recorded on your applications page.

There is no address to write to and no intermediary to call. The mandate holder reads what the Terminal delivers and nothing else, which is what keeps the process the same for every applicant and keeps your name out of it until you release it. Applications close on 11 October 2026. Mandate reference CVU-PER-2026-IND-132.