The Aspire platform wasn’t designed around a fixed set of financial products. Its engineering choices assumed expansion across markets, regulatory regimes, and transaction types that hadn’t yet emerged. That assumption shaped everything from how the platform integrated with banks and regulators to how it handled multi-currency flows, compliance boundaries, and operational scale as transaction volumes grew into the billions.
Giovanni Casinelli, Co-Founder, CTO, and President of Aspire, explains how a small number of early architectural decisions continue to define how the platform scales today. In this interview, he reflects on the trade-offs between monoliths and microservices, global and regional deployments, synchronous and event-driven systems, and where AI is now beginning to influence both operational workflows and engineering practice as Aspire’s financial services footprint expands.
Which early engineering choices still shape how Aspire’s platform scales today?
When we started building Aspire, we made a few architectural bets that felt bold at the time but have since become the backbone of how the platform scales.
The first was committing to an API-first approach long before we had banking partners or multi-market products. This forced us to think of Aspire not as a closed system, but as an integration-ready platform that could connect with banks, regulators, and ecosystem partners with minimal friction. That decision later made it possible to expand into other areas.
The second foundational choice was investing early in a unified domain model and ledger. Even when we offered only a handful of financial services, we built a transaction engine capable of supporting multi-currency, multi-entity flows. That early discipline around domain boundaries and data structures meant each new product line could be layered on without impacting the core fabric of the platform.
The third choice was cultural as much as technical: an emphasis on observability and automated testing from day one. As transaction volumes grew into the billions, that early focus allowed us to keep moving quickly without compromising reliability or compliance.
How has Aspire’s tech stack evolved as it added more financial services?
We started with a fairly typical monolith: fast to build and well-suited for early product-market validation. As our product roadmap expanded, so did the need for speed and team-level independence. That’s when we began transitioning to domain-aligned microservices, each with its own deployment pipeline. This allowed engineering teams to ship independently without risking the stability of the broader system.
As new product lines emerged, we leaned into a modular, service-oriented architecture. This provided the flexibility to add new capabilities without rewriting the core, and ensured product teams could innovate without waiting on large-scale platform changes.
Finally, we adopted an event-driven architecture built around Kafka. That shift proved significant. It enabled real-time transaction processing and clear, asynchronous communication between services, which became essential as we expanded across markets and began supporting more complex financial workflows.
How did Aspire balance building in-house systems with using third-party services?
From the start, we chose to build the systems closest to money movement. Owning this end to end gave us the ability to scale across markets without inheriting limitations from external providers.
We took a different approach in areas where partners bring deep specialisation or where speed matters more. KYC (know your customer), AML (anti-money laundering), card issuance, and FX (foreign exchange) and compliance APIs are all domains where integrating with trusted third parties allows us to move faster, stay compliant, and focus engineering effort on what differentiates us.
Payments acceptance is a good example of how we approach these trade-offs in practice. Aspire is still early in building the full depth of payment acceptance capabilities. Rather than slow ourselves down, we chose to partner with Stripe initially. This allowed us to learn, remain flexible, and go to market quickly without compromising user experience or compliance.
Which architectural assumptions did Aspire have to revisit as it scaled?
One of the biggest shifts was moving from a synchronous model to an event-driven one. In the early days, synchronous calls were fast and simple. Once transaction volumes increased and services became more interconnected, those dependencies began to slow us down.
Transitioning to Kafka-based eventing fundamentally changed our resilience and latency profile.
We also moved away from regional silos. Initially, each market had its own deployment tailored to local nuances. As we expanded, this approach became a barrier. We moved to a global platform with standardised service contracts, supported by regional infrastructure only where data residency required it. This created consistency and ensured robust compliance.
We also strengthened the overall architecture as we added more regulated products, ensuring systems evolved in line with MAS, PCI-DSS, and other compliance requirements.
Where is AI adding tangible value in Aspire’s financial operations today?
One of the most immediate gains has been in back-office automation. AI now supports processes ranging from onboarding checks to financial crime triage, helping teams process information faster and with greater consistency. It doesn’t replace human judgment, but it reduces the manual effort required to reach informed decisions.
We’re also seeing an impact in developer productivity. AI-assisted coding, automated testing, code reviews, and documentation have shortened release cycles and allowed teams to focus on higher-value work. This has changed the rhythm of engineering at Aspire, enabling teams to ship more confidently and iterate at a pace that matches the needs of a multi-product financial platform.
These are still early steps, but they are laying the groundwork for what comes next.
Editor’s note: This interview was first published in Frontier Enterprise 2026.
