Compliance: Don't Let the Form Become the Substance

Across Trust & Estate operations, compliance requirements can be implemented in very different ways. Consider two banking environments:

1️⃣  In the first, estate administration includes an established reporting form that has to be completed manually several times during the life of an estate. The form has been in use for years, and some of the information it asks for is no longer particularly relevant. But changing it has become difficult because multiple stakeholders would need to agree on what should replace it.

So the form survives, and every estate continues to carry the administrative burden.

2️⃣  In the second environment, Compliance has identified approximately 15 things it wants verified before an estate can be closed. Those requirements have been incorporated directly into the operating process.

When the team reaches closing, the system can generate the required compliance report with a single click, using information already captured during the administration of the estate. More importantly, if the required conditions have not been satisfied, the system can prevent the estate from being closed out in the system.

Both organizations have compliance requirements. The difference is that one has made compliance an additional process people have to perform, with many manual steps. The other has made compliance a customer of the operating system.

Requirements are not mechanisms

Compliance may say that once an estate has been closed, it needs verification that 15 particular things have happened.

That is the requirement.

It does not necessarily follow that someone should have to complete a 15-question form manually. That is simply one possible mechanism for satisfying it.

A better operating model may ensure that the relevant tasks are completed, the required information is captured as the work progresses, the appropriate approvals take place, and the resulting evidence can be assembled automatically when needed.

💡 The requirement has not changed. The mechanism has.

The difficulty comes when the two gradually become fused together. The form is no longer seen as one way of satisfying the compliance requirement; it starts to become the requirement itself.

At that point, changing an inefficient process can start to feel risky. If a field is removed, is the control being weakened? If the form is no longer completed at a particular stage, is a compliance gap being created? If the process is redesigned, will the new approach still satisfy the original intent?

Faced with those questions, it is often easier to leave the existing mechanism alone. That is how organizations can continue performing work that almost everyone knows could be done better.

Compliance should specify the outcome

A cleaner model is for Compliance to specify the outcome it requires, rather than prescribing the mechanism used to achieve it.

Suppose Compliance requires confirmation that a particular review has occurred before an estate can close.

That requirement can be built directly into the operating process:

✅ Assign the right task to the appropriate role.

✅ Capture completion as part of the matter record.

✅ Reflect it in the closing report.

✅ Prevent closure if the requirement has not been met.

There is no need to recreate the evidence later, because the work itself produces it.

That is an important shift.

💡 Instead of performing the work and then completing a separate compliance exercise to demonstrate that it was performed correctly, the control becomes part of the way the work is done.

The practitioner may experience little or no additional reporting burden, while Compliance still receives the verification it needs. More importantly, there is a direct connection between the compliance requirement and what actually happened in the matter.

What happens when the requirement changes?

This approach also makes compliance easier to adapt.

Suppose Compliance adds a sixteenth closing requirement. In a form-driven process, that can mean redesigning the form, changing procedures, distributing the new version, and making sure everyone starts using it.

If the requirement is already part of the operating model, the change may be much simpler. A task may need to be added. The closing report may need another item. A new condition may need to be satisfied before the estate can be closed.

The requirement changes in the operating model, and the normal operation starts producing the new result.

There is no need to create a separate process around it.

Compliance as a customer

This is what it means to treat Compliance as a customer of the operating system.

💡 A customer specifies what it needs from the operation. It does not necessarily dictate every step used to produce it.

Inherent Visibility for Management works in much the same way: Management needs visibility into what is happening across matters, teams and offices, but the best answer is not to ask everyone to stop periodically and create that visibility through separate status reports. It is better if the information is produced naturally as the work takes place.

Compliance can work the same way.

Compliance specifies its requirements for:

🔷 Controls

🔷 Evidence

🔷 Outcomes

The operating model incorporates those requirements into the work, and the platform produces the evidence that they were satisfied.

Compliance should specify the requirement. It should not have to become the mechanism.

When those requirements are built into the operation, compliance becomes an outcome of doing the work correctly rather than a separate exercise layered on top of it.

Inherent Compliance.