TRM in FinTech: Tech or Compliance?
By: Samuel Bourque
Tags: Trm, Compliance, Fintech, Regtech

This will surely ruffle some feathers…

Good then. Let’s jump right in.

TRM is a Hot Potato

Ask your average, conservatively-dressed, bespectacled Compliance Officer in between KYC checks: “Who’s responsible for TRM?”

The likely answer is: “Technology.”

If you manage to catch your average T-shirt and jeans wearing tech guy away from his keyboard and corner him into a reluctant human-interaction: “Who’s responsible for TRM?”

The likely answer is: “Ask Compliance for policies.”

Institutional TRM

TRM is not new. It has a long, sordid, barely-noticed, less-than-illustrious history in banking institutions. TRM is unassuming, barely-visible, never-newsworthy in appearance; but is rather mission-critical in scope and importance.

In the past couple of decades, institutions have an ever-shrinking Operations Department whilst maintaining an ever-increasing Compliance/Risk Department(s). This is one-part due to automation taking hold in Operations, whilst the Emergent Technology Risks have become unwieldy. This leads to an ongoing case of “regulatory fatigue”.

Institutions have generally adapted by hiring a new department: Tech Risk — parking it between Compliance and Technology.

FinTech TRM

That’s all well and good for large, well capitalized institutions — but what of the small, nimble, budget-weary FinTech start-ups?

It is doubtful that there are many FinTech start-ups that are capitalized enough to hire a team focused on Tech Risk. Furthermore, TRM is practically never on anyone’s immediate radar in the inception stage of a new venture.

Inevitably, you end up with the TRM hot potato. As you might expect, neither compliance nor tech people have the sufficiently calloused hands to handle the impeding heat from the regulator.

When the Question First Comes up

It’s post-launch.

The next set of features are scheduled for release. There’s trouble — the seams start showing — perhaps there is an outage or two. The management then asks the now-obvious question: “What’s our TRM process?” All the department heads turn towards the Tech Lead who nervously does a double-take: “What’s TRM?”

“It’s a regulatory requirement!” replies the rest of the room. The tech guy points to the Head of Compliance: “All my regulatory requirements come from him.” The Head of Compliance — who’s generally quiet in the meeting room — is unfazed; he thumps a large purple binder on the table, pulls out a thick stack: “Here are the regulator’s TRM requirements.”

The Tech and Compliance Heads look at each and say in unison: “You expect me to understand this?”

TRM is Technology

This is obvious — why even get into it? It’s simply about ensuring that techies do their job right. How could anybody else understand what tech risks even are? let alone how to manage them?

TRM is Not Technology

Hold on a minute… the common skill set of techies are their ability to build systems according to specifications. Last anyone checked Risk Management is not on any Computer Science curriculum.

TRM is mostly a policy-making exercise —why in the world would you expect the tech experts to be the ones drafting legalese sounding policy documents? Especially when the technology talent is usually offshore and is on contract.

Judging by how difficult it is for the business side of the FinTech startup to explain their needs to the techie, it’s plain to see that the communication gap is rather wide. How would you expect to be able to understand such a policy drafted by a techie? You might have more luck reading the source code files— at least the techies are experienced at writing those.

TRM is Compliance

It’s a simple proposition: Compliance’s raison d’être is to ensure regulations are adhered to.

TRM requirements come from the regulator — do we need to spell this out?

TRM is Not Compliance

As much as both the Tech and Compliance members can generally not be expected to interpret the TRM regulations, its rules apply to the Technology’s procedures.

As an example, the code review requirement is probably not best served by having a Compliance Officer review the source code— it’s not any more appropriate than having a movie critic review a movie in a language he does not understand.

TRM is Both Technology and Compliance

I hope it’s obvious by now: TRM is a shared responsibility.

Technology and Compliance must work together in firstly interpreting the Regulations.

Guess what?: they will disagree on many interpretations… but consensus must be reached.

Put their respective strengths to work: have the Compliance talent prescribe how policy is drafted, and how to track the audit trail; have the Technology talent integrate risk controls into their procedures. Both are equally hard and require a lot of effort.

The hardest part of all though is: communication. I.e. reaching consensus on what needs doing, and each side to educate the other on what is needed. That means clear speaking and good listening… unfortunately that is not what each one is well-known for.

TRM is Neither Technology or Compliance

Confused yet?

The ultimate customer of TRM is actually the Board. Recall that the RM in TRM is Risk Management.

TRM processes may identify many risks, but the Board has ultimate accountability. It must be made aware of risks: to assess and treat them.

For there to be a proper RM/TRM Framework, the Board must review risks — hopefully from an articulate Risk structure — in order to make well-informed decisions on whether to either control for risks, or accept them.

That begs the question: how do you structure all this together into one framework?

… to be continued