Compliance and transparency: the foundation of cross-border fintech

When you start a financial technology company, it is easy to think of regulatory compliance as a toll: something you pay—in time, in lawyers, in friction—so you can get on with what really matters, which is building product. After years operating across jurisdictions, I have come to the opposite conclusion: compliance is not a toll, it is the road. Without it, no financial product survives more than one regulatory cycle.

Compliance as architecture, not a checklist

The first thing any team building financial products learns is that compliance is not added at the end, like a coat of paint on a finished building. It is decided at the design stage: what data you collect, who can move it, which jurisdiction each operation lives in, which regulated provider handles each sensitive piece—custody, banking, payments—and what record remains of every decision.

Treating compliance as infrastructure, rather than paperwork, changes the technical decisions from day one: how onboarding is designed, what gets audited, what gets documented, and which regulated third-party providers are involved in each part of the process.

The questions every fintech team should be able to answer

Team size is irrelevant: if the product touches other people's money, there is a handful of questions you must be able to answer without hesitation:

• Who holds custody of the user's funds or assets, and under which licence?
• Which regulated provider performs each sensitive function—banking, payments, currency exchange—and what exactly is your company's role relative to that provider's?
• Which jurisdiction governs each contractual relationship, and what does that mean for the end user?
• What KYC and AML controls are in place, and who audits them?

If a founding team cannot answer these four questions with precision—not with a vague "the lawyers handle that"—there is a design problem, not just a communication problem.

What I learned operating between Spain and the Middle East

Expanding operations from Barcelona to Dubai has been less a change of address than a stress test of this way of thinking. Every new jurisdiction adds its own regulatory framework, its own licensing timelines and its own expectations about what must be documented. What can be managed with common sense in a single jurisdiction demands explicit processes across several: who is accountable for what, which regulated provider covers each piece, and how you demonstrate to a bank or a regulator that the structure makes sense.

Transparency, in this context, stops being an abstract virtue and becomes an operational tool: the more clearly you understand—and can explain—who does what and under which legal framework, the less friction you have with banks, regulators and, ultimately, your own users.

Why this matters even before anyone asks

The temptation, in the early stages, is to leave compliance for "when it becomes necessary". The problem is that when it becomes necessary—a funding round, a new banking relationship, an audit—it is too late to design it well; all you can do is patch it. Building with this discipline from the start does not slow the product down: it prevents the entire product from later depending on a structure that no one can explain clearly.

Note: informational and educational content. It does not constitute legal, regulatory, tax or financial advice, nor an offer of services. Verify every obligation with qualified advisers and the competent authority.

Sources

• FATF-GAFI — international anti-money laundering standards.
• European Banking Authority (EBA) — guidelines for payment and credit institutions.
• SEPBLAC — Spain's anti-money laundering authority.