the policies, procedures, disclosures, advertisements, and product
features to make sure that they conform with existing regulations.
Compliance officers must make sure that any lingering compliance questions have been answered. The product needs to be fully
analyzed to make sure that all pertinent regulations have been
addressed. In addition to traditional regulations that may affect
the product, what other regulations exist for the digital space? If
it’s an online lending product, have
Truth In Lending Act requirements
been met as well as eSign?
These products no longer exist
in a vacuum, but rather must integrate with regulations that now
apply to the digital space. It may
also prove beneficial to reach out
to regulators with whom you’ve
established a relationship. This is
especially true if you may be pushing some boundaries or operating
in a regulatory “grey” space.
Legal review is when the finishing
nuts and bolts are placed upon the
relationship. Master Service Agreements are finalized. Any financing
and investment agreements are
executed. Prenuptial agreements
may be signed to pre-determine exit strategies based on nonperformance of one of the parties, and timelines are officially
established. Any lingering compliance or contractual issues are
finalized and the relationship between the bank and the Fin Tech
company is officially consummated.
All of the compliance teams involved, whether internal or external to the bank, need to have input into the compliance aspects
of the contract. For example, compliance should ensure that all
third-party guidance is followed. The contract should allow the
bank periodically to conduct audits and the contract should allow
for termination if not all compliance requirements are met. The
contract should also call out what the service level agreements
are, state when any reports need to be provided and when audits,
and reviews must be conducted. Allowing a certain degree of
flexibility is good, but it should also outline what is required to
meet expectations for all of the parties involved.
Once all of the hand shakes have been completed, it’s time to start
working on the development of the product.
For any product development cycle, a roadmap must be created.
This roadmap is essentially the timeline associated with getting
the product ready to go to market. To create the roadmap, the
company must define all of the features it wants to enable in the
product, then prioritize the features in the order that it wants
to roll them out to customers. The
reason for the prioritization is that
resources are typically limited.
Whether it’s engineering resources
or financial constraints, the features
must be prioritized so the ones that
are most needed hit the market,
and the customers, first. Once the
resources are allocated based upon
the prioritization of the features,
the timing can be established and
milestones can be created to keep the
product on track for the established
It’s important to note that in many
cases with financial product technology, other vendors and technology
providers may be involved. This
creates additional considerations
for scopes, timelines, and integration requirements among multiple technology teams. Compliance teams need to understand the milestones associated with the
timeline. If additional disclosures or collateral need to be created
or reviewed, there should be clear dates on when that will be ready
and who is responsible. Compliance also needs to be aware of any
changes to the plan and be ready to opine whether there is any
type of negative impact that would affect the overall roadmap.
Now the fun begins—the engineering team gets to build all of the
fun things that have been talked about during this entire process,
typically working with third-party vendors to provide additional
resources. Code is written, apps are built, and even hardware or
access devices are created. Once a version of the product is created,
it’s time to try to break it through strenuous testing. Every time a
bug is found or something is broken, fixes must be implemented
to release a product as flawless as possible. When it’s debugged
and fixed, it’s time for another round of testing and breakage. This
is an ongoing cycle until the company feels that the product can
be released into the marketplace as close to perfect as possible.
While this is often thought of as an engineering responsibility,
compliance officers should get in on the fun as well.
Review the disclosures in multiple formats, especially if this
will be a web and mobile release. Are they legible? Is collected
information being received and stored as expected? Does the
application accept Post Office boxes when your Customer Identification policy dictates that it must be a physical address? Ap-
Compliance cannot be an afterthought.
It must be embedded into the product and
the process at every step of the way.