Crafting a Treasury Tech Ecosystem at Block

Joseph Drambarean:

Welcome back to FinTech Corner. We’re here still at AFP, day two, and I’m joined by one of my longtime friends, Mark Brogna. We’ve been working together, I think at this point. Is it three years

Mark Brogna:

More than that.

Joseph Drambarean:

If it’s more than that? Oh my God

Mark Brogna:

I was still in an office I think.

Joseph Drambarean:

That’s right. And I had a pass, so I came into the Square office, so it has to be then since 2019, so yeah, four years. It’s been an amazing run. And as I mentioned pre-show, I had some time to think about this one because one of the things that I have found fascinating about Mark is that in the world of treasury, your role I would say is either undefined or non-existent or it’s emerging. And I wanted to maybe begin by describing to the audience, which is primarily in the world of finance and treasury, what is it that you do today at Block, formerly known as Square for those that aren’t aware? And how did that happen? How did your role, this kind of more engineering focused, systems focused role come to life?

Mark Brogna:

Yeah, that’s a great question. I ask myself that all the time. Thankfully, I’m very happy at Block because I don’t know how I’d go and seek out some other role anywhere else at this point. Sure. I can start maybe back at my beginning experience at Square when we were still square. So I actually come with a background of public accounting. So when I joined Square in 2012, we didn’t have a treasury team at the time. I had become aware of the company and I actually had a friend from college who was working there and was talking to him about what was going on at Square because I was looking to get into more of a startup type environment. And I came in and talked with some folks on the accounting team. That was kind of the natural connection point for me. And they were looking for this role that was at the time really focused on the, because all our revenue at that time was from the processing fees. We take off a transactions for the credit card processing transactions,

And they had built this new reconciliation tool, which was called Fred, which stands for Financial Reconciliation Database. And they were trying to figure out how to extract information and using actual queries and a MySQL database because it’s such large amounts of data and how to then create systems to record the revenue track that build some reconciliations because I think the struggle that they’re facing is traditionally when you’re doing revenue recognition, maybe you want to have an invoice, you check to make sure it’s been received by the vendor or the customer and go through those basic four principal revenue recognition. It doesn’t really apply. You’re more dealing with this large dataset thing. And it kind of was hard to wrap people’s head around. So they were looking to fill that role and I guess I’d gone through a few iterations and it just kind of fit for me. So I joined the accounting team doing that originally and there was sort of flavors of treasury operations I’d call it at the time, because like I said, all of our revenue came from this percentage. We would take as money moved through our bank accounts. So I was having to have a responsibility of being on the bank portals. I would do some sort of basic treasury operation functions.

I was doing that for about a year or so. And as a business was growing, there was this need for more of a treasury function and we tried to hire a more experienced treasurer. I was not equipped for that role at all at that time, but there was someone else in the company who had kind of just a really smart guy, learned all about how chargeback disputes worked within cart networks. And he had built our first disputes team at Square and they asked him if he wanted to try a new role and set more to this treasury function. So he took on that role and I had worked with him and we had been talking and he asked if I wanted to stay in accounting or if I wanted to try something else. And I definitely didn’t want to stay in accounting. The thing that drew me to Square, even sending back in the first place was just, it was a place I really found a lot of smart people. So especially back then it was about 300 employees. It was a really great, it still is, but especially then a really great environment of learning from other people. Everyone I interact with, not only do they know what they’re doing, but if you experienced this when people really know and then they can teach you even if you have no experience with it, it was that type of environment. And so he was someone who he actually helped build a lot of data and SQL skills that I had none of before joining Square.

Joseph Drambarean:

I have felt the same in my career. I owe my entire career to folks like that, that were ultra smart, that were willing to teach me ultimately how to do what they do and let me become a version of them even of a small little slice.

Mark Brogna:

So that was then what got me more into a treasury path, I’d say. But again, both myself and my former manager, none of us came from a treasury background. I think the draw for us was because Square had so much of the product centered around banking, financial technology solutions, there was this natural marriage between maybe business type functions like a treasury role and product and engineering side of things. And that was actually a gap that early on we filled, and that’s where I spent most of my early years within the treasury team focused on was sort of being this business partner around what we call our merchant settlement process. So we would have payment based engineering teams. One group was focused on, we call the acquiring side of things. And so they’re building connections with payment acquirers, payment tech, first, data, amex. And the way our systems run is that there’s an independent flow of information between that payment acquiring inflow side of things, and then we call it the merchant settlement side of the house.

Joseph Drambarean:

It’s vast volume.

Mark Brogna:

Yea, lots of volume. So part of that is we don’t want, that was part of the basis for Square is starting a small business, you shouldn’t really have to know the nuance of this network funds at this cadence. This network has batching scheduled, sorry, batching schedule this way they just are making a sale and then they should get paid as soon as possible. And so what we were doing behind the scenes was kind of running a settlement process that was agnostic to whatever card you were accepting. That was sort of the complexity we would take on because we felt better suited to solve that problem as opposed to small businesses that aren’t going to have a full staff of corporate functions probably. So on that merchant settlement side of thing, there wasn’t really a business owner or business user that was partnering with them.

And most of that stuff just comes from the bank treasury stuff itself. I mean, we were connecting just through their basic HOSA host file-based applications to send Aach H files the same way that corporate treasury teams with partnering with an ERP system would. I think the difference was that we probably staffed it a lot more because it was a business critical thing. That’s right. We had to run daily, like you talked about high volume of transactions and we couldn’t miss. And so that’s where the path of you talked about being close with engineering teams really came out of that would be the group I’d sit with the most. I was understanding the relationship between events happen in a database and banks don’t move at the speed of information and it’s gotten better. People like Trovata and have helped to close down that gap. But thinking back 10 years ago, the bank’s technology infrastructure was way lagging behind what the general technology practitioners were used to.

And so there’s a gap that existed a long time square of people not understanding that, okay, we said this thing was paid out, but when does actually money get to the merchant and trying to understand the ACH system. So that’s kind of the role I was fitting in to help bridge that between the two side of things. And then I spent a lot of time after that initial period when I joined this treasury function is when we started going more into our international expansion. So that was my focus for a few years was every new market we went into, I would just try to understand

Joseph Drambarean:

How do you get it up and running?

Mark Brogna:

Yeah. Is because I’ll say to all of our merchant business is all domestic based. We don’t have an international hubbing of where we’re paying out of. So we have to set up local banking operations. We have to understand the local domestic bank transfer system that’s available and figure out how are we going to offer this consistent square experience but tailor it to what maybe the market nuances are, whatever that banking infrastructure is.

Joseph Drambarean:

So it’s funny that you say that and you’re happy at Square and Block. So this is just a hypothetical, but I think I know what your role would be. It’d be in product because at the end of the day what you’re doing is playing a role where you craft requirements and a vision for a business critical system, and then you organize engineering capacity, whether it’s vendor or not, to execute on that vision. I think that’s where our relationship I think began. It was, and I guess to rewind the tape back when we met in, I guess it’s 2019, it has to be 2019 for the first time, Trovata was an engineering program of under 15 people. We were really small and you had really big problems. They were related to data aggregation, data synchronization, volume. That was another issue that we had to kind of think through. And what’s interesting is that Trovata has grown together with your organization at the same time.

Mark Brogna:

Yeah, I’d say, and also personally within my function that I sit in right now, it really, so I talked about the career path that went up to the point, but now my current role I sit in was really born out of taking on this new problem that was specifically tackling, I think having reliable bank information for all the different end users in our company to be accessing and then reconciliation. That’s been a key focus. So I have been working on different areas of this throughout a lot of my time at Square. And it wasn’t getting any better. It wasn’t getting easier, like the scale and the number of markets and products we were in just kept growing. I raised concerns that we couldn’t keep tackling this without a true systems approach to it. That was where I put this proposal together that we needed to tailor a specific function towards this.

The end goal is just improving the visibility that we have of how customer transactions move through our network of bank accounts. And so I focused primarily still on what I call our customer product side of the house to me a little bit more interesting because I get to pretend that I’m in the product side of things and hang out with those people more. But the problem that we started with of the visibility, lack of visibility into this that we wanted to see so we could be making smarter decisions on how our cash management procedures were happening when we started asking the question like, okay, why aren’t we there? And then the first answer was, well, we don’t have a system that’s completing the reconciliation to all the bank activity consistently.

So we said, okay, well let’s figure out what do we need to get there? And then the question came up of, well, why haven’t we built this yet? And then that’s where we got to the point of we didn’t have a reliable and consistent source of electronic bank data. We kind of viewed it as we had a real data problem that existed and we needed to have a pipeline of bank transactions that could be stored and manipulated and kept a log of that kind of state of reconciliation that could then become our new data set or data source for this sort of enhanced reporting we wanted to be. So that’s I think also lined up with growing our relationship with Trovata and you kind of talking about building this focus on not just collecting the bank information for us, but actually making it accessible into whatever data systems that you may be using at your company. And I think that’s kind of where things have taken off for us.

Joseph Drambarean:

From our perspective, there are, I’d say two primary challenges that emerged from day one. And I’d say that all customers of Trovata have benefited as a result of the exercise that we went through together. The first was the scale piece. It was could we asynchronously connect to all of these independent connections? API file-based, it doesn’t matter. It will bring in data digitally and do it at a scale of millions of transactions and it happening in the second challenge in a quality state where you can accurately reconcile. And I think the second part was the complicated part. What we do in terms of connectivity, given enough time and effort, pretty much anybody can do it, right? You just have to attack the problem. And we’ve gotten way faster better in every regard. It’s the second side of the equation, the quality of service of if you do a file-based setup today, you receive your statement.

If there’s anything wrong with it, that BAI statement or CAMT file, that’s it. You have to go to the bank and say, can you give me another one? And then they may or may not come back to you with a solution and deliver it on time from at the time square’s perspective and now block the wider ecosystem. That’s just unacceptable. And it’s not just a matter of completedness of data, it’s turnaround. Hey, we found this issue now within days we need to fix it because we need to hit our month end close or our weekly goals of whatever it might be. And I think that’s what we have found is that we had to build over time healing mechanisms that as far as we can tell, just don’t exist in the industry. And it’s that algorithmic detection of issues with data and healing of that data that can only be done through automation because as you guys experience yourself, if you throw human capacity at this, you just will never keep up. There’s just too much data.

Mark Brogna:

Yeah, that was a fall on my face I think early on. Where people struggle too is you get to a point of data scale, it’s so abstract that it’s hard for people to conceptualize and kind of understand where the boundaries exist because you can’t touch it. And that’s why you need to have a system based approach, at least in my perspective, because you go beyond the limits of what the human processing can actually achieve.

Joseph Drambarean:

Exactly. And I think the other thing that we learned over time, and this is where to get back to the point of why I’m just so fascinated by your career is that you represent an archetype that at least for high growth tech companies, I believe is going to be the future. This archetype of a role where you’re kind of that product mindset and you build product internally that is bespoke to your organization, but that is built on APIs. And that’s the other thing that emerged is that over time, I think at this point we have 13 or 14 independent teams at Block that are building on the Trovata API platform. We didn’t plan for that. That just kind of was a natural, I guess, development of the ecosystem just coming to life. And that’s where we started to see the possibility of, I wonder if this is where the puck is going, if the industry will just start to behave in this way because you walk around a FP right now, everybody is trying to provide a solution. They’re trying to say, buy our software, which solves this problem. Instead, you’re walking around this hall thinking to yourself, I’m just going to fix our problem and I have engineering capacity to do that.

Mark Brogna:

Yeah. I think, I sometimes wonder if we’re in a bit of unique position. That’s sort of what I’ve enjoyed so much about my time at Block is that our products are rooted in finance. So I also do think that lends itself to a lot of this overlap where I never experienced it personally, but as an auditor, seeing it in other companies where corporate type functions are not actually seen as the boogeyman too product people who are trying to grow and build things, and you’re just there to tell ’em what they can’t do because there’s expertise that we have that actually overlaps with what the products are trying to build. I talked about it with this role we had where we were the ones that were talking with the banks and a lot, one of the core functions of our product of getting money to people relies on bank systems.

And so that’s also where I think a lot of the push internally, or I say the justification for this building things ourselves is you make the decision and the assessment of is it something that’s actually critical to the business operating? And that just was pretty clear to us that we have to have reliable reconciliation systems, not just to make the job of our finance teams easier, but also it’s critical to making sure that the business is operating as intended. But I think what we had seen with, especially on the bank reconciliation side of things, was for a long time there just wasn’t, I mean, you could connect directly with the banks itself, but I talked to all the engineering teams that now work with it and they’re very thankful that they’re not the ones having to manage with the connectivity and that itself offloading to another party. I think they’ll greatly appreciate.

Joseph Drambarean:

And I think when I try to think about the line, because over the years there’s been the constant temptation I’ll call it, of volunteering and saying, oh, we could solve that problem for you. And I think where I’ve seen that line kind of emerge is when you have expertise on your side of the house on how your business operates, that’s the line. We shouldn’t be involved on that side of the house where we have expertise on how the wider ecosystem of banking data, financial data and how it all flows and how it can be optimized and then connected to you. That’s where we can play a role. And it started to kind of click in my mind that if you extrapolate this out outside of block, and I guess if you were to give advice to folks here at AFP, and I think there are plenty of examples. I think you’re right in terms the nature of your business is unique, but there are other businesses like Uber for example, or Airbnb gig economy businesses where their end customer is both me getting a ride, but also the taxi driver who’s expecting a payment five times a day hopefully for their services.

Mark Brogna:

Those are all payments companies.

Joseph Drambarean:

Exactly. Payments companies. Apple’s another one. There’s a massive payment company at this point. You would never think it, but they’re a huge payments company. And I wonder, do you have any advice for folks that are trying to make a decision around, Hey, do I buy a piece of software or do I buy almost like engineering capacity instead? What’s the better ROI if you play this out over the next five to 10 years?

Mark Brogna:

I think your point of being clear about where the line is that’s so critical to it, I think you have to be really honest about what is it the role or the job that you are hired to do is and be really rigid where you can about, that’s where the focus will be, right? And so if you’re a company that’s making this bill versus outsource type of decision, and you have to do the same thing, like I said about we build things internally because we address it as this is part of the actual business operating itself. If the role is serving some corporate back office function and you have to ask the question two questions I think you have to ask is do I need to do this myself? But more importantly, can I, do I have the ability to secure engineering and technical resources at the quality that makes sense to build this?

And is it something where there’s enough work? This is the other thing I learned when I was talking about a lot of this building stuff and getting more into talking with engineering support and technical teams at the company. Clearly just talking about do I need to start hiring engineers to work in a treasury team? It didn’t feel right to me. And because I don’t think you want engineers to be part of a non-engineering thing, that can create an odd culture, but also you want to have that knowledge sharing, that learning that happens within a strong technical culture side of things. And you also, when we talk about this critical data infrastructure, the uptime managing it, some things you have to think about is on-call rotations, which people point out. And if you’re talking about, well, I only need two engineers and that’s all I need to support this, but then you’re signing up just two people to always be on call and there’s a burnout risk factor. If you don’t have the, I think capacity and having more of a, like I say, this function fits into a broader organizational structure where you can support it, then it’s a pretty easy decision where you would outsource hire that technical solutions because it’s just a better, I think, approach to solving those problems.

Joseph Drambarean:

It’s funny, I remember two years ago, I think it was having this thought in my mind where you and I stopped showing up to standups more often than not, and I thought in my mind, oh man, it happened. We finally grew up. The wider teams are able to pick up the load. And I thought that that was something that was also not built into the equation upfront of just like, Hey, we’re going to do this. We’re going to embark on this together. I think we both learned that once you build something, you are on the hook for maintaining it evergreen. It will never be turned off. And so it’s not just the infrastructure of code, it’s the infrastructure of people and operations. And that’s one thing too that I wonder about often, especially as treasury programs with I guess wider finance operations become more powered by their own business systems. Do they have that built in to the cost of doing this and have they considered,

To your point, maintaining a culture that will keep engineers happy, that will keep project managers happy, they’ll keep treasurers happy, all these different outcomes all at the same time? This is fascinating. I mean, I think that most people here are not thinking about the world in this way, and they should because it’s probably going to happen over the next few years, especially as businesses are just going straight digital and most businesses are becoming payments companies because they have to be. I’m curious, we’ve been at this for a while, four years, that’s a long time. We’ve gone to college together. Effectively, what does the future hold? Where do we go from here if we feel like the data problems are starting to be figured out and automation problems are starting figured out? What does the role of innovations like machine learning and AI play in our future? And do you guys spend any time thinking about that?

Mark Brogna:

Yeah, sure. Someone actually, we were having the speak at the panel conversation and it was asking if the API payment stuff was going to be able to incorporate machine learning to just even handle the air resolution stuff. Yeah. I said, that’s not how it’s done today, but I’ll raise my hand up for any of the bank people here. Yeah, feed that into your system. So I think that’s to me where there’s lots of exciting opportunities. We’ve talked, I think a lot about the pain points that have existed in this bank reporting space. You sort of have this trade-off unfortunately to make between speed and resiliency. So hopefully we can kind of merge those two closer together because as there is this more on-demand, real-time need for payments, but we all know the pain points and the headaches that exist if they’re getting too fast, but then it’s wrong, it’s almost worthless.

So I feel like continuing to see those two past merch together and start having this really truly robust data warehouse of bank transaction information that can be relied upon is huge. And then a lot of what we’ve done and my team over these years that we’ve been building up our function and some of our reporting and applications is trying to at least start answering the questions about knowing what we have. And I think for us, what I’m trying to see in the next few years ahead is, okay, now we actually know where we stand. How can we start actioning on this information? Because a lot of this stuff, systems are driving it. It’s not random. There’s some rules that were put in place. As long as you have a good way of capturing those rules and can understand the relationships, then there’s a lot of pass towards more automation. So that’s what I’m looking towards.

Joseph Drambarean:

I think about this often too, and I have to admit that when I think of it from the perspective of block and working with you guys and then from other customers, I change. And the reason is because so much time is spent in today’s activities when considering our relationship with you guys on defense, trying to make sure that data is accurate, trying to make sure that at the scale that we process that everything is bulletproof. And I think that if I were to wave a magic wand, it would be anomaly detection, becoming really bulletproof and doing it in a way where we can trust it. I think that’s an area where I really hope that investments in machine learning will pay off,

Mark Brogna:

Like I said, and then that’s the next step of not just the detection, but then once you have can map what’s the resolution path. That’s what I’ve talked about too with folks on my team as like, okay, it’s fine to maybe be alerted more quickly if something’s off, but then thinking about what are the steps that you take to then resolve it? A lot of times it’s kind of like a standard, you send an email, you probably could come with a form-based email that you’re sending to some contact at the bank and letting them know, well, if you’re doing the same thing every time, once this first step happens, that’s perfect for automation right there.

Joseph Drambarean:

Exactly. That’s exactly where my mind goes is that I think about the annoying things that we all have to do to just keep things running, and that’s always my magnetism is to that it’s not like, oh, I want to figure out a cool little insight. You have to earn your way to offense. I feel like when you deal with scale, and it’s been fun to do this over the last few years, and obviously I hope we keep doing it together for the foreseeable future. Thank you so much for joining us. Yeah, my pleasure. This has been an awesome conversation. I’ve been curious about it for a while, so it was great to hear your take. Yeah, no, always get a chat with you, Joseph. Awesome.