Compliance Without a Human in the Loop — Pavle Krivokuća | Fireblocks

So um thank you all for coming in the morning to listen talk about compliance. No burd seells unfortunately on this one very dry but bear with me I'm going to try to make it as fun as possible. So for the last three and a half years I've been building compliance products at Fireblocks mainly focusing on you know uh building your KYTS travel rules all the inherent checks that today's compliance uh world requires in a kind of as seamless way possible as you know less you know disturbed way as possible when you're doing transactions and operating end to end. So there's obviously a lot of talk now about agenting payments around AI about how can you know the future of the whole industry will move towards humans doing nothing and everything happening in the background kind of magically. Um and one important piece in that that uh you know we we need to face is you know how we do compliance and how we tackle compliance flavors and checks in that kind of new and emerging world.

So uh I'll try to achieve two things um in the next 15-ish minutes. So one uh not talk that much about you know what we're actually building and you know what we're doing but rather talk about the learnings and what we've seen you know bringing compliance products to very wide set of customers across the globe and two try to give you ideas around you know what are some maybe u compliance primitives what's kind of coming up and what are the some of the you know problems that we need to tackle as a you know collective industry and and builders uh in years to come. So starting off um if you think about where the transaction starts now obviously there's many different ways to it. One you know there's the old school kind of manual or semi-automatic or even in some casing programmatic approach when you know you initiate a transfer from point A to point B. Um and most of the compliance that that we know today has been built in this kind of shape and form.

If we think about it, you know, the the compliance tooling and the compliance checks are nothing new, are nothing revolutionary like you know, you have your travel rule that is stemming from 1996 regulation. So nothing new and crazy. It's just trying to get the application in the digital asset context and you know the whole um payment flows that we are seeing today. Uh the the other three you know is it a embedded wallet and an app? Is it you know a payment flow we are the API?

Is it you know an agent paying for something somehow? Um yes is bringing great speed is bringing great usability but it has kind of you know um I wouldn't say a a fault point but you know we need to kind of bake in and think about the compliance checks as part of that in a kind of systemic way. So uh you know if if we're thinking about the poor compliance officer on the other side you know who's who's been a you know buffer zone for majority of these these flows today you know you can on one side say oh the advertise job is you know for a compliance officer compliance office you know you're doing the reviews and checks you're building your S sur reports you're doing whatever you need to kind of do on on that side but uh the actual job is you know you're basically a human buffer you know you're you're trying to kind of make sense out of a complex system. you're trying to be flexible when you know on one side you have operations who are pushing for let's have you know as fast payments as fast transactions let's not waste time let's you know drop the latency let's you know think about how can we know uh increase the volumes and do everything on the other side you know you have a very strict regulators who be let's be realistic for the most part you know are still getting familiar with the whole you know digital asset space and how these kind of you know checks can be baked in. Um and you know that rigidity and that you know flexibility on the other side basically kind of uh you know breaks in on the compliance officer.

Compliance officer as a role in an entity be it outsource or in-house is kind of the same thing. So uh you know uh my point being that that human or that team is that kind of flexible layer and if you're planning to remove the human out of the equa equation of the transaction from point A to point B we need to start thinking about what does it mean to bring these types of checks and flexibility in a more systemic way and you know uh you know removing a person yes it might drop cost it might you know help with a lot of different things across the board but at the same time if we are not building the proper building blocks to achieve so you know we're we're kind of doomed to fail whatever the setup is like are you a big payment company are you cryptonative are you a bank are you you know wherever part of the ecosystem are you are you basically so in the next couple of slides I I'm going to share with you some of the you know uh feedback or considerations we received during you know maybe more like past year year and a half from different customers when it comes to kind of thinking about So let's build a more you know robust compliance systems and you know what are the actual facts that that are kind of uh popping up. So first one uh you know having one provider and no uh no fallback um I would say this is the most common ask coming in from a different customers just to paint you a picture today Fireblocks has roughly 2500 customers globally roughly 30% of the all the transactions in Fireblocks that are happening are going through a kind of a compliance check so it's already there customers are using it it's getting a let's more and more absorption especially with the new crowd coming in but at the same time you know uh we've seen customers who let's say historically had a single kit provider they might be using galysis or elliptic or TRM labs and now they're thinking about okay if I get a false positive if I get you know um unsupported asset or not you know fastly enough supported asset if I get whatever you know the you know fault or failure might be for the first and primary provider I'm using the next logical thing you say, "Oh, let's introduce a secondary provider that will, you know, allow us to kind of perform a, you know, add-on check to kind of have a better coverage, less for positives, you know, all the all the good stuff. Um the uh historically like why we couldn't do it because like when we were designing original kind of compliance system on our side, it was kind of very straightforward like oh, you use one type of KYT providers, you would use another type of travel rule providers and that did serve majority of the use cases for quite quite a while. Now that's breaking and you know providers um need to become more flexible in the eyes of the user so that you can kind of you know connect the dots and actually you know uh have a very very different use cases depending what you want to achieve.

you know, you might be willing to wait a certain, you know, timeout to pass if you're doing, you know, BTC versus ETH transactions or if you're doing a certain kind of settlement or a payment. And then, you know, bringing that kind of additional flexibility is something that is kind of much much needed. Um there's also like you know in all honesty like still you know if you ask different customers what does it mean? Um there's not a single answer like you know some customers would say uh yeah we want to have a secondary provider whenever there is a rejection or a failure. Others would say no we would run to you like to run a you know parallel checks and then you know have like you know uh you know quick win or you know first fail or whatever kind of strategy for kind of you know marrying the different results popping up around it.

Um second point that we've seen kind of across the board is you know the order of checks and then this has been like again very widely debated at least in my circles when I'm sleeping with customer is what do you do first uh each screening each kind of check cost you money obviously it cost you time because it increases the latency from point A to point B to receiving the money but also more importantly if you're doing a flavor of a check with any KYT OFAC sanction, travel rule provider, you name it. You're paying for a screening. Each screening costs you depending obviously what you do you agree with the specific provider. And then let's say you have a transaction or a transaction order coming in and you say oh let's do the full stack. Let's do I don't know uh address registry of sanction KYT travel rule all the bells and whistles.

Each of those will cost going to cost you money at the same time. You know uh that might not be the proper order. You know the obvious one that we did a while back was oh if you know KYT fails probably [snorts] we can say that doesn't matter you know you shouldn't be doing travel rule because the KYT fail then you know it's a high risk anyhow so no need to go into the whole PII conundrum and travel rule message complexities but uh on the other side uh you know is it is it a is it a great approach for all the different flows that uh that you know might be there uh historically this was hardcoded on our side you know we had a very specific order of checks that could happen so we would you know logically from from you know that standpoint say oh let's do kit first if kite fails or is bypassed uh you know uh then no matter we we shouldn't be doing the travel rule you know check uh depending on what you're doing what we're seeing uh today is that more and more customers are you know if the vanilla compliance for a long time was you know I'm doing transaction cture like I'm doing these checks at the point of either transaction initiation outgoing or if I'm doing the check whenever I see an incoming transaction coming in it's enough it's enough in the eyes of the regulator I'm good I'm doing you know what I supposed to be doing if you look at the threadfi and what that grim future holds in a way is that you would be doing compliance checks in kind of three separate surface areas for any and all you know transactions funds moving in and out and that's a pre-transaction world the transaction world than a post-transaction world and that's that's a you know traditional finance default today. Obviously it's not going to be copypaste in the same manner but especially for non-cryptonnative crowd big institution coming in that is kind of you know that's the default if you have a bank that wants to do something on you know blockchain they will first say okay no we need to first go and validate all the addresses all the people and everything before we even whitelist them and put them in a context of you know doing some or any transaction for that matter so the order is definitely fix. It's something that you know we're also trying to tackle and uh you know once on one side you will have that context of you know the order of checks and the amount of checks from a compliance side will increase the latency one way or the other but on the other side you'll most probably will not be able to do transaction if you're not doing these things if you're a license holding entity.

uh failure three uh you can't remove what you don't need and I I guess this whole point is mostly around optimizations like you know it's kind of leaning on the previous one you know if I did a KYT and KYT failed should I do travel rule I would say in general sense probably no but depending what you're trying to achieve and do you might you might might want to do it so optimizing that and then you know optimizing that will you know both on the cost side of doing less checks but also on the kind of time optimization side like saving time when you're doing the actual kind of end to end transaction. Um what we're seeing more and more from from customers feedback is like you know they they want to have this kind of as a something they can control and they can configure when they're setting up their you know uh layer behind. Uh point four uh is you know bring your own checks for for a very long time you know we were very focused to bring let's bring more providers let's bring you know more control more customization at the end of the day like you know if we have enough providers and just to kind of state like uh today we do have one of the most advanced compliance product stacks in the world in terms of you know digital assets in terms of like sheer number of providers supported and customization you can build on top of that and it's still not enough like we're still seeing customers who say, "Yay, that's great, but I don't want to be using elliptic directly through Fireblocks. I have some additional, you know, uh, logic and features that you guys don't support and we want to be running a native integration for whatever reason there." So something that's kind of also popping up is that even if we kind of say let's you know imagine a perfect world where we integrate it with all the providers and we provide the all the flexibility some of the primitives that are required for compliance today are going to be very specific to a customer and something that customer will probably never share with infrastructure provider a third party provider whoever a simple example of that would be oh let's imagine you I'm running operations and one of the internal checks that I have it can be arguable is it you know compliance or operations but is the account that I'm trying to receive money to or send money from an active customer a very simple one like and the answer for you know some of the customers on institutional side will be yeah I'm not I'm not you know using the sale account of a non-active customers I don't want to be receiving any money there it's creating exposure for me but that's in the internal check from some internal database or somewhere that I need to perform in my all compliance operations.

Um and then for the long time we we kind of didn't uh we couldn't build it in an easy way uh purely because like our system was designed around oh there's a provider there's an explicit response we react on that response and make a verdict make a decision. How do you make a verdict when there's no third party provider? Um and then you know you know the obviously obvious answer is like you give customer ability to provide the verdict one one way or the other. Um the point that I'm kind of coming to hopefully is that you know the the the system uh that whatever system we had we currently have has a certain level of the opinion baked in um and it was never kind of exposed and expressed. So um what do I what where I'm coming from is that you know um when people are talking about compliance becoming an infrastructure uh it's actually you know the the most critical part in my eyes is exposing the defaults exposing the whatever baked in you know controls you have in place of such you know product or family of products and giving customer ability to control this stuff because like you know depending where you're sitting in the world the default the minimal bases or whatever is going to be widely different.

Uh my old favorite example is you know you're trying to do for example travel rule doing travel rule in US versus Europe versus South Korea is wildly different and widely widely different. So you have your like US flavor today which is like do you do your best you know like a for effort like whatever you send is good whatever you try is good you're proving that you have a mechanism to do travel rule honestly majority of the flows don't have you know proper travel rule in place if you're doing Europe you know with the Doras and Mikas you know you you kind of have a very set you know flavor but still open to interpretation like try and reach out your counterparty for appropriate amount of time. What's the appropriate amount of time? We've seen customers that waited 30 seconds and say, "All good, we tried. Move forward."

We've seen customers who did why vice versa and said, "Oh, let's wait for seven days. If there's no response, fail the transaction and everything in between." In South Korea, you know, we we could argue like it's it's for my sake at least one of the more elegant travel rule implementation. It's very simple like you can't do transaction without a travel rule. You can't initiate a transaction without a travel rule.

do the whole thing before you initiate a transaction. And then when the transaction happens, any counterparty checks, is the travel part of this? Yes, great. No, fail, reject. We don't want to be touching this because, you know, we'll be fined ton of money uh in the process.

And then you know the the uh the these opinions these kind of you know layers is something that today customers need to you know decide on themsel depending where they are sitting in the world you know where their license holding uh and also making sure that you know we have uh a good uh you know good setup to support them whoever is on the builder side of things. Um and then very interestingly enough because we are running a lot of these checks for our customers the and I would say the default setup of any let's say product and R&D would be you know you're expecting the failures to come from bugs from product not being good enough from product you know lacking things and yes there is a bucket of that nobody's ever built like a perfect thing but at the same side majority of the uh issues that we're seeing today across customers is are misconfigurations are you know stuff that you know product is behaving as it's supposed to just customers are not using it in a proper way and then you know we can make an you know discussion around usability user experience you know how can we build those uh but inherently you know we um uh it's it's a customers trying to understand in a kind of very vague regulatory frameworks what they are supposed to do what's their internal compliance appetite and policy when it comes to these things and what's the risk they're willing to get exposed. Obviously, you know, the the the business model that are based on speed will always look like can we have as super fast compliance checks? You can, you know, you can accept everything. You know, you don't need to wait too much time for stuff, but you know, that's that's the risk you're hopefully knowingly are taking in and taking into into consideration.

Um, also the flexibility, the obvious one, doesn't remove failure. we you know the the false positives the you know whatever flavors of checks there are still going to happen one way or the other um and in all honesty you know even today we don't have a great you know solution for that like you know yeah you can introduce a secondary provider you can introduce more controls or more flexibility but at the end of the day like um you know the failures are still going to happen hopefully you know the the type of failures that you as a you know compliance office compliance officer are willing to kind you know make and not impact the the business in a too negative way. Uh in a very kind of brief sense uh the based on all of this what we're building today is what we're calling a compliance orchestrator a new engine or a layer on top of all the checks and connectors we we do have today with you know steps uh are not like hardcoded. Customers can configure what's the order of checks they want to do today. Um also, uh customers are going to be able to use different vendors in a different manner for different types of flows.

Um and hopefully have like a one solid schema to kind of run it run it end to end. Uh but you know be beyond that uh just to echo like there are obviously things that we don't have answers for then I'm always willing to learn more when it comes to kind of you know whoever is willing to discuss compliance with me afterwards. Uh but you know um as I mentioned like false positives are still there. We don't have a great solution for those. Um not you know uh every request coming in is for more screening.

It's for cost optimization. It's for kind of figuring out how can you build a better engine end to end that's not impacting business too much. And also like you know the defaults that I touch based upon are widely different. You know do you do you build a default that is always conservative? Is it good enough?

Is it you know good enough for majority of customers and what do you do with those customers who who have a different different approach and a lot of these things are something that um eventually will need to expose be exposed one way or the another for customers to configure with a very brave hypothesis of that customers know what they're doing and you know they they know what they need to need to build kind of end to end. Um but you know bringing kind of my hopefully you know uh talk to to the to the main point is you know the approve button the approval the compliance check that you know was kind of embedded one way or another in a kind of manual flows or you know review role of the compliance office. Um you know it's it's not a UI element. It's not like inherent thing that you know oh they can always go and click and check what happened. It needs to be like a systemic decision and a way that you kind of build in your whole suite because you know in honesty like more regulation is going to come and it's going to be more specific and more demanding on whoever is a license holder in a specific jurisdiction.

The question is like you know can we offer as builders proper tools so that you know uh they can really streamline the operations and you know achieve whatever we want to achieve as an industry be it agentic payments being you know a more fluent financial system uh but yeah so uh I guess these these were the main points uh thank you for listening into compliance in early in the morning that's that's always appreciated and happy to take any Does anyone have any questions about compliance?