Construir fintech no Golfo: o que aprendemos em Doha

Entregámos um produto fintech para um cliente em Doha. A parte de engenharia não foi a difícil. O calendário regulatório foi - e apanhou-nos mais lentos do que devia, e é exatamente por isso que vale a pena escrever sobre isto com honestidade, não como o destaque de um caso de estudo.

A resposta curta

Nada disto torna o Qatar um mau mercado. Torna-o um mercado onde a sequência das decisões importa mais do que o código.

Um país, duas jurisdições

A primeira coisa em que tropeçam os fundadores vindos de mercados com um único regulador: o Qatar não tem um único quadro regulatório financeiro, tem dois que importam para a maioria dos produtos fintech.

O Qatar Financial Centre (QFC) é uma jurisdição legal e regulatória distinta, com o seu próprio direito das sociedades, quadro fiscal e regulador de serviços financeiros, separada física e legalmente do resto do Qatar apesar de estar situada dentro do país.

O Qatar continental, sob o Banco Central do Qatar e outros reguladores nacionais, tem o seu próprio quadro de licenciamento separado para serviços financeiros.

Qual deles se aplica ao seu produto nem sempre é óbvio de fora, e não é uma decisão a tomar depois de o produto estar construído. Determina a estrutura da sua entidade, o seu tratamento fiscal, com quem pode operar bancariamente e, nalguns casos, que regras de residência de dados se aplicam. Errar aqui não significa ajustar uma funcionalidade - pode significar reestruturar a empresa.

O calendário que realmente importa

Eis a sequência que apanha quase todos os fundadores fintech estreantes da região: orçamentam cuidadosamente o tempo de engenharia e tratam o licenciamento como uma tarefa de fundo que corre em paralelo com o desenvolvimento. Não funciona assim.

O envolvimento regulatório começa antes das decisões de arquitetura, não depois. A categoria de licença que persegue afeta os requisitos de tratamento de dados, o desenho da trilha de auditoria e, por vezes, que regiões de nuvem pode usar - tudo caro de refazer depois.

As relações bancárias demoram mais do que a construção do produto. Estabelecer uma relação bancária ou de infraestrutura de pagamentos conforme no Qatar frequentemente ultrapassa em meses uma construção de MVP de 8 a 12 semanas. Se a relação bancária não avançar em paralelo desde a semana um, torna-se o verdadeiro estrangulamento do lançamento, não o software.

A categoria importa mais do que o tamanho da empresa. Um produto de pagamentos que gere fundos de clientes fica na ponta longa do calendário - mais perto de nove meses do que de quatro. Uma ferramenta de software B2B que toca em dados financeiros sem mover dinheiro avança mais depressa. Saiba o que está a construir antes de estimar uma data de lançamento.

Infraestrutura de pagamentos: o que se integra diretamente e o que não se integra

Esta é a parte que surpreende especificamente as equipas de engenharia, não só os fundadores.

Alguns prestadores de pagamento internacionais têm licenças ou acordos de parceria locais que permitem uma integração mais ou menos habitual. Outros exigem encaminhamento através de um intermediário local licenciado, o que muda a sua arquitetura, os seus prazos de liquidação e por vezes a sua estrutura de taxas - de formas que não são visíveis até estar profundamente envolvido na integração.

Isto tem de ser verificado por prestador, por categoria de produto, antes de ser projetado no sistema - não descoberto durante os testes de integração, quando refazer sai caro. Tratamos isto como parte do dimensionamento módulo a módulo em qualquer projeto fintech do Golfo precisamente porque muda o custo e o calendário mais do que quase qualquer outra decisão isolada.

O que diríamos a um fundador que começa hoje

Três coisas, pela ordem em que gostaríamos de as ter ponderado desde o início.

Comece a conversa regulatória na primeira semana, não depois de construir um MVP. Envolva um advogado local ou consultor de conformidade antes de a arquitetura ser finalizada. O custo de fazer isto cedo é baixo. O custo de descobrir um requisito de licença depois de construir o fluxo de dados errado não é.

Separe "qual jurisdição" de "qual licença" como duas decisões distintas. QFC versus continental é a primeira bifurcação. A categoria de licença específica dentro dessa jurisdição é a segunda. Os fundadores muitas vezes reduzem isto a uma única conversa e ficam com uma resposta apenas meio certa.

Trate a relação bancária como um fluxo de trabalho paralelo desde o primeiro dia, com o seu próprio responsável e o seu próprio calendário, não como um item que acontece depois de o produto estar pronto. Na nossa experiência, é mais frequentemente a restrição real da data de lançamento do que o software.

Onde isto corre bem

Nada do que foi dito acima é motivo para evitar este mercado. A estrutura regulatória do Qatar, assim que se percebe que partes se aplicam, é mais previsível do que mercados com quadros fintech mais soltos ou menos definidos - exigente no início e comparativamente estável depois de a atravessar. Os produtos que acertam a sequência enfrentam menos surpresas regulatórias mais tarde do que em mercados que parecem mais fáceis de entrar no primeiro dia.

Os fundadores que têm dificuldades são os que importam um manual de "construir primeiro" de um mercado onde isso funciona. Os que se saem bem tratam o licenciamento como a primeira decisão de produto, não como uma caixa de conformidade assinalada a posteriori.

Está a definir o âmbito de um produto fintech para o Qatar ou o Golfo em geral? Conte-nos em que ponto está - diremos com honestidade como é um calendário realista. Os nossos preços e modelos de colaboração estão publicados abertamente.