Marco Pirrongelli, Managing Director of GOAT Finance, started his career in the trenches of data centers and cloud infrastructure, where hands-on problem-solving and leadership gaps demanded stepping up. Today, he applies that battle-tested mindset to architecting a secure, scalable OTC crypto-fiat platform that bridges TradFi and Web3.
In this post, Marco shares GOAT Finance’s technical vision as an “octopus” forging financial connections, core principles like compliance-by-design and security-first development, hands-on insights into MVP iteration and regulatory tech decisions, and bold bets on AI agents and interplanetary finance over the next 3–5 years.
Tech vision & architecture
How do you define GOAT Finance’s technical vision as an OTC‑focused crypto‑fiat platform, and what core architectural principles guide your stack (e.g., scalability, security, compliance‑by‑design)?
From a technical standpoint, I define GOAT Finance as an octopus that is forging connections and managing various branches of finance in order to solve the major challenges that exist in both traditional finance and Web3 when it comes to cross-border payments. The fundamental principles that guided my choice of the technology stack are scalability and compliance (which inherently includes security).
MVP & product‑engineering balance
You’ve built and managed GOAT’s MVP in production; how do you prioritize features, tech debt, and reliability when iterating on a live trading platform used by thousands of clients?
As is well known, an MVP is not a final product but rather a proof of concept (PoC) designed to learn from your customers, understand the operational and technical limitations of the team and the company, and—most importantly—identify solutions to address those limitations. Technical debt is a burden for every technical team; we have addressed this through development guidelines and code quality standards. Features are developed with the following three groups in mind: 1. The user, 2. The operations team, and 3. The compliance team. – Interacting with so many users is challenging and requires a lot of infrastructure. Today, thanks to AI agents, we can say that the work has become more manageable, but it is not yet time to let AI do everything on its own.
Balancing speed and quality
Give an example of a time when business pressure pushed you to ship a feature quickly, but you felt the code or architecture was risky. How did you balance speed, quality, and risk?
We have never prioritized the product over security. If a feature isn’t ready—even if it means missing a deadline—we’d rather wait a couple more days to release it, ensuring that we don’t compromise anything. For us, the most important thing is our customers and the trust they place in us. As a financial institution, it is our obligation to make the security of everything we deploy our top priority. To that end, we always follow best practices.
Security, compliance, and AML
How do you embed security and AML controls into the codebase and data flows without slowing down product velocity?
Something I have learned over time when building products is that suppliers have their own infrastructure. Nowadays, it is very easy to create embeds or proxies that read this information and store it in our system for recordkeeping and failover purposes. We mix and balance to prevent the product from becoming too slow, but I can’t deny that today, with so many regulations and things tightening up, financial products (not just goat) have been slowing down, which causes a lot of friction with the customer. We have solved much of this with automatic and manual processes that must meet certain KPIs. For example, an order cannot remain open for more than 15 minutes if there is no indication that Compliance needs to review it, and an RFI must be sent within 40 minutes of receiving the order. These rules guarantee efficiency for the customer.
KYC/KYB and identity stack
GOAT integrates third‑party KYC/KYB solutions like Sumsub; how do you design the integration layer to balance user experience, data privacy, and real‑time risk‑screening requirements?
We use Sumsub. We design integrated systems using Sumsub SDKs to maintain the highest level of security and comply with regulatory requirements and those of our banking partners. Currently, data is always handled in encrypted form when we communicate with external providers, and data is also stored in encrypted form in our databases and repositories.
Trading‑system design
What are the key technical challenges in building a low‑latency, high‑integrity OTC matching and settlement engine, and how do you handle edge cases like price slippage or partial fills?
We do not operate like a traditional exchange; our OTC settlement system is more direct, and latency is not a factor here, since the customer is always waiting for the best price but also expects the capital to be available to exchange for crypto. We do have what we call partial fills, but these are based on the challenges of obtaining liquidity. Sometimes less than the total amount is obtained, and in this case, we obtain different prices.
Team, culture, and delivery
With a lean team, how do you organize your engineering and DevOps squads, and what practices (e.g., agile, on‑call, documentation) do you emphasize to keep delivery predictable?
We are currently a team of almost 10 people in IT who use Agile and hold daily meetings. All use cases are documented by our AI agents and validated in two phases, by the developer and by each of the stakeholders, including the customer.
Regulatory‑driven tech decisions
How do evolving EU and Swiss crypto‑regulatory expectations (e.g., MiCA‑adjacent rules, FCA‑style standards) influence your choice of databases, logging, and audit trails?
In many ways, since each regulation has its references to different privacy laws. For example, in Europe, apart from GDPR, we now have DORA, and in Switzerland, we have the FADP, which, despite having similarities, each has certain fundamental points that must be taken into account. For example, Swiss regulations require me, as a service provider, to tell the customer if the data is going to be moved outside the country and shared with other European entities. Another example is that Switzerland requires us to perform a Satoshi test to confirm ownership of the customer’s wallet.
Interoperability with crypto rails
GOAT’s product sits at the intersection of traditional banking and crypto rails; how do you design APIs and connectors to support multiple stablecoins, blockchains, and payment rails without creating a fragile monolith?
This is a very good and interesting question. Startups often create monoliths that end up being a headache in the future, both technically and in terms of scalability. Thanks to our experience building other systems in the past and the expertise we have gained from studying best practices, we have avoided this and developed using methodologies such as CLEAN and KISS. These methodologies ensure that we can continue to develop and scale the business while eliminating the risk of creating a monolith.
Leadership & initiative
Tell me about a time you had to step up and lead a technical initiative without being formally asked. What did you do, and what was the outcome?
Early in my career, I was deep in the technical trenches. Installing servers, working in data centers, hands-on infrastructure work. I was not leading teams yet. I was learning the foundations.
The turning point came during a project in Panama. A group of us set out to build a cloud infrastructure that could deploy all kinds of servers at scale. There was a designated leader on the project, but he was heavily focused on the business side, so a leadership gap opened up. Nobody formally assigned me the role. I just stepped in, took ownership, and the team followed.
What made it work was trust. I earned it by being present, by solving problems, and by keeping the project moving. And the results spoke for themselves. The company grew 230% as a direct result of the services we delivered and the cost savings from migrating physical server premises to the cloud. A single-purpose physical server became a flexible cloud environment running multiple instances simultaneously.
That experience taught me something I have carried ever since: leadership is not always assigned. Sometimes you have to recognize the gap and fill it.
Future‑proofing GOAT’s stack
Looking ahead 3–5 years, what technical bets (e.g., AI‑assisted operations, agent‑driven workflows, new consensus layers) are you most excited about, and how do they align with GOAT’s long‑term roadmap?
Since 2019, when the first foundational AI papers began circulating, I have been saying the same thing: we will be replaced by robots and AI. It is a fact. Whether people choose to believe it or not is their own concern.
Over the next 3 to 5 years, we are building our own LLM focused on fighting financial crime and fraud, alongside AI agents that will redefine the way we develop software. And this is just the beginning. In the next decade and beyond, the transformation will be unlike anything we have seen before. The pace is already staggering.
Think about it in historical terms. We went from libraries and encyclopedias to the internet, and the internet changed everything. AI is doing the same. After AI will come robots and humanoids, taking over physical labor and routine tasks, freeing humanity to focus on what truly matters: exploration, discovery, and expanding our presence through the universe.
At GOAT, we are already asking questions that most institutions have not even considered yet. How will interplanetary transactions work? Once we reach Mars and beyond, who governs cross-planetary trade? What infrastructure handles financial flows between civilizations separated by millions of miles? These are not hypothetical conversations for us. They are strategic ones.
There is an enormous amount of work ahead, and we are building with that horizon in mind. GOAT is not just playing in today’s market. We are positioning to be a player for the greatest era of all times.