June 18th, 2024 - Regulation Innovation SIG Meeting Minutes

[eteridvalishvili]

Regulation Innovation SIG

Date

June 18th, 2024 - 12pm EST / 5pm BST

Untracked attendees

• Fullname, Affiliation, (optional) GitHub username
• ...

Meeting notices

• FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

• All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

• FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.

• FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

• Convene & roll call (5mins)
• Display FINOS Antitrust Policy summary slide
• Review Meeting Notices (see above)
• Approve past meeting minutes
  • Agenda item 1
• Leveraging Open-Source Collaboration and Snowpark for Turnkey Solutions in LCR Compliance - Stephen Goldbaum, Morgan Stanley, Luis Fallas Avendano and Mauricio Rojas Fernandez, Snowflake
• Insights and Innovations in SupTech from the Cambridge SupTech Lab - Matt Grasser, Cambridge SupTech Lab.
• AOB, Q&A & Adjourn (5mins)

Decisions Made

Action Items

Join Zoom Meeting

https://zoom.us/j/95819415471?pwd=VmxmeExMcXJFZWs4OGtnTXBiWnVHdz09

• Meeting ID: 958 1941 5471
• Passcode: 915672
• Find your local number: https://zoom.us/u/acoFmoLAFE

[Josephrp]

Joseph Pollack - Tonic-AI

[toshaellison]

Tosha Ellison - FINOS

[blanchab]

Alan Blanchard - TSO

[iansloyan]

Ian Sloyan - FINOS/South Cardinal

[jgavronsky]

Jane Gavronsky / FINOS

[lucaborella89]

Luca Borella / FINOS

[DGHakkodan]

Karen Meppen/ Hakkoda

[sfc-gh-mrojas]

Mauricio Rojas / Snowflake

[sfc-gh-lfallasavendano]

Luis Fallas / Snowflake

[iansloyan]

Thank you Matt Grasser for the presentation on SupTech work you are doing at Cambridge University.

Considering the presentation and the one before which demonstrated the technical challenge of complying with just one regulation published by a supervisor. I have a couple of questions/topics for discussion (one long/one short!).

1. (you partially answered this towards the end but I would like to expand on that in a future discussion -) SupTech and RegTech being separate themes always confused me. Supervisors receive data from entities that they regulate legally, or have some tacit control over, to provide them with data to do their supervisory duties.
   Is this actually understood widely by the Supervisory community? - or do they understand the burden and technical challenge faced by financial institutions to collate and prepare all the data to comply?
   If it is understood, then key principles of SupTech development must be: reducing the volume of data that is required, reusing data that is already collected, publishing regulations with reference to international data standards (including as regulations code for easy implementation), recycling the instructions/code for different regulations.
   (When viewed globally and broken down into constituent parts financial contracts both retail/consumer and wholesale/financial market deal with a pretty manageable menagerie of products and processes which can be well described by some existing global data models/standards - and the supervisory tasks if approached from the same perspective as the institutions (using their same data models) can be greatly enhanced and quality drastically improved. Generally each supervisor is doing the same thing just in a different jurisdiction, but labelling things according to a local taxonomy.)

2. (a less long winded Question/comment I promised) What regulators and supervisors have been most supportive and open to your work to date?

[mr-z-ro]

Hi @iansloyan thanks for the kind feedback and the questions! I'll do my best to answer here with my personal views, but would be happy to connect and discuss more as you see fit.

1. I'm seeing three components to your question here: whether there is a substantive technical distinction between framing regtech/suptech, whether that is broadly recognized, and what are the fundamental (shared) goals. So I'll do my best to break those out and speak to each.

   1.1 Regtech and suptech. Indeed, these two terms have evolved largely separately. In my experience, people generally use "regtech" to refer to compliance tech and other private sector manifestations of data tools for preparation, analysis, and submission of regulatory data, while "suptech" speaks specifically to the tools required by public sector financial authorities to collect, validate, store, process, analyze, and present insights related to their supervisory mandates. This is, for example, the framing that the BIS Innovation Hub has stated explicitly (see page 2, paragraph 2). However, my position for the past decade, which is now the position of the Lab, is that these are "two sides of the same coin" (e.g., a panel I moderated and one of the SupTech Week sessions both referenced this term).

   1.2. The recognition. Whether Consumer Protection, Prudential, AML, or otherwise, I have yet to work on a solution that doesn't benefit from at minimum substantial design inputs from supervised entities. In many cases (probably most notably for compliance reporting API clients) the solution itself must include what is typically seen as a "regtech" component to complement the supervisor-facing value (in the case of APIs, this would the server and any downstream analytics platforms). A pain for a supervisor at the collection layer (e.g., redundant data points) tends to correspond to a pain point for the supervised entity (e.g., unnecessary costs borne in producing redundant reports). So as an explicit part of our "supervisor-centered design" that I referenced in the presentation, we collect inputs via questionnaires or interviews with supervised entities to understand their pains, existing tools, etc, and take advantage of this. So I cannot see an optimally designed system functioning without this input, but I am unsure whether that is broadly recognized so formally beyond the Lab.

   1.3. The goal. As you aptly observe, in an ideal world there would be exactly one transmission and validation of each relevant data point per period, no more no less. In fact, in one case, we have accomplished this goal at the collection layer working with the Central Bank of the Philippines and supervised entities, building off the prudential case study linked above. Once that data is in place, I also agree that leveraging some of the algorithmic treatment of compliance data from the private sector solutions into the . Many of the vendors in our SupTech Vendor Database include private sector value prop as a core portion of their work. When I created the Practical Data Science for Financial Supervision course, I explicitly made the decision to include several live presentations from private sector providers as part of the curriculum to start this cross-pollination. Transparently, this aspiration plays a role in motivating my engagement with this FINOS community as well, wherein much of the software and community here is sure to be valuable for public sector solutions.

2. While we commit ourselves to remaining neutral in terms of relationships with financial authorities, I can share that our SupTech Solutions Tracker, our Innovation Leader Residency, and our Application Incubation partners (soon to be published as case studies) each highlight key collaborations with authorities. I will share as a general observation that many innovative suptech solutions we've worked to develop have come from emerging markets, which can tend to surprise people who tend to focus only on the most prominent brands in this space. Whether it's leapfrogging or simply ability to build a suptech-native team from the start, there is often a benefit to having less legacy infrastructure even in the face of less financial resources. But of course we've worked with authorities all along these spectra.

I'll leave it there for now, and hope my matching your questions with even more long winded answers has been helpful :) As mentioned, I'm happy to connect directly and/or return for a follow up presentation as well, if useful.