Strawbay’s platform is built as one engine that serves every customer, with hard isolation between them, security designed in from the first line, and resilience that assumes things will go wrong. We sat down with Andy Kovalov, who leads the platform and engineering at Strawbay, to talk about the choices behind that design.
Strawbay sits in the middle of regulated financial flows, connecting client portals and core systems to the many ERP systems their customers run. That position carries a high bar: the data has to keep moving, it has to stay inside the EU, and no customer can ever reach another customer’s information. We asked Andy how the architecture is built to meet that bar.
“We deliberately built one engine rather than a separate stack per customer. One well-understood, continuously hardened platform is far safer than dozens of variations nobody can fully reason about. The strength is not that every tenant has their own copy, it is that every tenant is strictly isolated inside one system we know inside out.”
Andy Kovalov, CTO, Strawbay
That isolation is enforced at the platform level. Each customer runs in its own namespace, and knowledge, data and tooling are scoped per tenant so that a request can only ever touch the information it is entitled to. The same boundary applies to the agent layer in the console: every conversation is bound to a user and their tenant, and access is fail-closed by default.
Security is treated as a property of the design, not a layer added afterwards. Personal data and secrets are minimised and protected, the platform follows the principle of least privilege throughout, and approval keys and access tokens are rotated and validated continuously rather than left static.
“Rotation is one of our quiet strengths. Keys and approval tokens are short lived and constantly refreshed and validated, so a credential is only ever useful for a brief moment. It turns a static target into a moving one, and that removes a whole class of risk before it can ever be exercised.”
Andy Kovalov, CTO, Strawbay
Resilience is the other half of the story. The platform assumes failure and is built to recover quickly: hourly backups, a tested disaster recovery process, and source code held in escrow so customers are protected even in the unlikely event something happens to the company. The aim is simple, the financial flows a regulated business depends on keep running, and can be brought back fast if they are ever interrupted.
“Our customers run regulated businesses on top of these flows, so resilience is not optional. We back up continuously, we rehearse recovery rather than hoping it works, and the code sits in escrow. If the worst happens, the data keeps flowing and nothing of the business is trapped with us.”
Andy Kovalov, CTO, Strawbay
All of it stays in Europe. The core platform and the financial data it handles run on Google Cloud in Europe, with no replication outside the EU. Strawbay operates as a data processor with GDPR built into the design, and the controls are mapped to the standards European finance is held to: privacy by design, EU data residency, and an information security posture that is certification-ready for ISO 27001 when a customer requires it.
“We hold ourselves to the standards our customers are measured against, because the formal review always comes, and we would rather be ready for it than scramble. EU residency, GDPR by design, controls mapped and ready for certification. It means a customer’s due diligence is a confirmation, not a discovery.”
Andy Kovalov, CTO, Strawbay
The result is a platform that is fast to deliver on, because there is one engine to build on, and trustworthy to run on, because isolation, security and resilience were designed in rather than bolted on. For more on how the agent layer works within these same boundaries, see our developers section.