How to Build Internal Accountability for Regulatory Implementation Across Departments

How to Build Internal Accountability for Regulatory Implementation Across Departments

The most common compliance failure is not that nobody saw the regulatory update.

It is that too many people saw it, and nobody clearly owned it.

A circular comes in. Compliance reads it. Operations is copied. IT is asked to check system impact. Finance says it may need data. Legal says interpretation may be required. Senior management is kept informed. Everyone is aware.

But awareness is not implementation.

Three weeks later, the question is still open. Compliance is waiting for operations. Operations is waiting for IT. IT is waiting for a requirement note. Finance is waiting for confirmation. Management assumes the matter is moving. The deadline moves closer.

This is not a people problem. It is an accountability design problem.

Regulatory implementation in a modern business is rarely owned by one department. A SEBI circular may require legal interpretation, operational change, IT development, client communication, exchange reporting, and evidence preservation. An RBI direction may require policy approval, product changes, merchant due diligence, finance reconciliation, and board oversight. A depository instruction may affect DP operations, back-office systems, client forms, and audit records.

Compliance may coordinate the work, but it cannot execute every part of it.

That is why firms need an internal accountability model.

The first building block is an ownership matrix. Many teams use the word “owner” loosely. That is dangerous. For every regulatory implementation item, there should be one accountable owner for delivery. Other teams may support, review, approve, or provide evidence, but one person or role must be responsible for moving the item to completion.

A useful ownership matrix should separate four roles.

The regulatory interpreter identifies what the update means. This is usually compliance, legal, or secretarial.

The implementation owner completes the action. This may be IT, operations, RMS, finance, HR, DP operations, treasury, product, or business.

The reviewer confirms whether the action satisfies the requirement. This is usually compliance, legal, risk, or a senior control owner.

The escalation authority removes blockers. This may be the compliance head, COO, CFO, CTO, CEO, or management committee depending on the issue.

This separation is important because many firms confuse coordination with ownership. Compliance forwards the update and follows up, but the action belongs elsewhere. 

If that is not clearly recorded, compliance becomes the default owner of everything and the real implementation team remains undefined.

The second building block is a proper handoff.

A weak handoff sounds like this: “Please check and confirm.”

A strong handoff says: “This circular requires a change in the client onboarding declaration by 15 October. Operations owns the process change. IT must update the portal field. Compliance will review the final wording. Evidence required: revised form, system screenshot, and communication to branches. First update due by Friday.”

That is a different level of clarity.

Every handoff should answer six questions: what has to be done, why it matters, who owns it, who supports it, when it is due, and what evidence will prove completion.

Without this, departments may respond with comments instead of implementation.

The third building block is early impact routing.

Not every update should be sent to every department. That creates noise. But the right department should be involved early enough to act.

Firms should create routing rules. If an update affects reporting, finance and compliance must be tagged. If it affects trading, RMS and IT must be involved. If it affects account opening, KYC and operations must review. If it affects cybersecurity, IT, risk, and vendor management must enter the workflow. If it affects board or shareholder matters, secretarial and legal should own the review.

This is where regulatory implementation becomes operationally mature. The update is not merely circulated. It is routed based on impact.

The fourth building block is escalation design.

Many organisations escalate too late. They wait until the deadline is close, then send urgent emails. That creates panic, not control.

Escalation should be designed before delay happens. The workflow should define what triggers escalation: no response within two working days, deadline within seven days, IT dependency unresolved, vendor delay, evidence not provided, disagreement on applicability, management approval pending, or high-risk obligation open.

Escalation should also be specific. It should not say, “This is pending.” It should say what is pending, who owns it, what is blocking it, what decision is needed, and what happens if the deadline is missed.

Senior management does not need more forwarded circulars. It needs exception visibility.

The fifth building block is evidence responsibility.

Every department involved in implementation should know what evidence it must provide. IT may need screenshots, deployment records, configuration notes, access logs, or test results. Operations may need revised SOPs, process notes, client communication records, or branch instructions. Finance may need reconciliations, filing acknowledgements, or calculation workings. Legal may need review notes or approval records.

Evidence should not be hunted after the task is complete. It should be defined at the time of assignment.

This small change improves closure quality immediately.

The sixth building block is status discipline.

A cross-functional implementation tracker should not have vague statuses like “pending” and “done” only. Those words hide too much.

Better statuses are more operational: assigned, clarification required, with implementation owner, system change in progress, pending approval, pending evidence, completed by owner, under compliance review, returned for correction, closed.

This gives management and compliance a real view of where the work is stuck. A task pending with IT is different from a task pending evidence. A task under legal interpretation is different from a task returned because the evidence is incomplete.

Status should show the bottleneck.

The seventh building block is reviewable closure.

A regulatory task should not close because the owner says it is done. Closure should mean the required action was completed, evidence was uploaded or linked, and the reviewer accepted it.

For material updates, closure should include a short closure note: what was implemented, when, by whom, and what evidence supports it. This becomes valuable during audits, inspections, handovers, and management reviews.

A firm that cannot explain how a regulatory requirement was implemented across departments is always vulnerable to reconstruction risk. Someone has to search emails, call old team members, and rebuild the story later.

That is avoidable.

The deeper lesson is that compliance accountability cannot depend on goodwill. Most people want to help. Most departments are not trying to ignore compliance. But they are busy, and regulatory work often competes with business deadlines.

A proper accountability model makes compliance work visible, assigned, time-bound, and reviewable.

The question every firm should ask is simple: when a regulatory update requires action from three departments, who controls the implementation chain?

If the answer is “compliance follows up with everyone,” the model is weak.

A stronger answer is: the update is logged, impact is mapped, accountable owner is assigned, supporting teams are tagged, deadline is set, evidence is defined, escalation triggers are active, and closure is reviewed.

That is how regulatory implementation becomes a management system instead of an email chase.

For senior management, this also changes the quality of oversight. They no longer need to ask for broad comfort. They can see which regulatory actions are open, which department owns them, which ones are delayed, where evidence is missing, and what requires intervention.

For compliance teams, it reduces the burden of being the organisation’s memory and reminder engine.

For departments, it makes expectations clearer.

Regulatory implementation is cross-functional by nature. Accountability must be designed the same way.