Travelex é um nome em que muitos confiam por sua experiência em câmbio e presença em aeroportos ao redor do mundo. A empresa está investindo na evolução de seus recursos digitais para otimizar os serviços internacionais de transferência de dinheiro e câmbio para consumidores e clientes corporativos.

Fundada em Londres em 1976, sua missão é “permitir o fluxo de dinheiro sem atrito através das fronteiras” e, graças ao crescimento orgânico e aquisições direcionadas, está atualmente ativa em 30 países com uma rede de mais de 1.000 caixas eletrônicos e 1.200 lojas em todo o mundo.

Dan Phelps, arquiteto-chefe da Travelex, é uma das pessoas que estão liderando a transformação digital contínua da empresa. “Nos últimos anos, tivemos sucesso no desenvolvimento de recursos fintech significativos, bem como na manutenção de nossa fortaleza tradicional no varejo”, disse Phelps. “Estamos em uma boa posição. Temos a confiança e a estabilidade que vêm de um histórico impecável de 40 anos no setor e, ao mesmo tempo, estamos criando soluções digitais de ponta para apoiar a inovação e a ruptura que são características das fintechs.”

A base para a oferta digital mais recente da empresa é criada na Amazon Web Services (AWS). Mais recentemente, a Travelex usou a AWS para fornecer alguns dos novos serviços da empresa, como o Travelex Wire— um serviço digital de transferência de dinheiro internacional. Esse serviço precisava estar em conformidade com os requisitos regulamentares do Reino Unido, o que foi facilitado com a AWS. “Temos décadas de experiência em conformidade com regulamentações financeiras em todo o mundo, mas esta foi a primeira vez que buscamos a aprovação para uma carga de trabalho em nuvem”, disse Phelps.

“Aproveitando as vantagens da AWS, o processo ficou mais simples e muito mais rápido. Não havia fornecedores de nuvem terceirizados para lidar, e um arquiteto de segurança da AWS trabalhou conosco de perto, compartilhou conhecimento do setor e, em última análise, nos ajudou a alcançar nosso sistema mais seguro até o momento — que todos os produtos e serviços da Travelex futuros herdarão.”

Chris West, líder de DevOps na Travelex, e seus colegas optaram por usar microsserviços lançados usando o Docker e Amazon Elastic Container Service (Amazon ECS), com uma estrutura de controles de segurança abrangente que incorpora AWS Key Management Service (KMS), Amazon Virtual Private Cloud (Amazon VPC), Amazon Web Application Firewall (AWS WAF) e outras ferramentas.  

Cada conjunto de contêineres, executando um microsserviço ou um gateway de API, tem tráfego distribuído pelo Elastic Load Balancing em execução na camada 4, portanto, os dados criptografados não precisam ser descriptografados para passar entre os serviços. A fim de minimizar o efeito da perda ou roubo de configurações confidenciais, todo dia os contêineres são reimplantados com novos certificados de segurança. West explica a arquitetura em detalhes neste vídeo como parte da série “This Is My Architecture”.

Um bom exemplo da nova e ágil maneira de trabalhar da Travelex é sua capacidade de reprojetar a Travelex Wire de um serviço focado no consumidor para um serviço business-to-business (B2B) em apenas 100 dias. Phelps afirma: “O mercado de pagamentos internacionais B2B representa uma grande oportunidade comercial para nós. Sempre soubemos que teríamos de girar em algum momento, e a oportunidade surgiu muito mais rápido do que o previsto. Com a arquitetura que construímos na AWS, conseguimos colocar nosso novo produto no mercado em três meses — facilmente na metade do tempo que levaria anteriormente”.  

Grande parte dessa agilidade vem da adoção de microsserviços. Isso inclui, por exemplo, serviços que processam pagamentos, buscam taxas de câmbio ou tratam de liquidações, bem como serviços voltados para o cliente que enviam e-mails ou textos. West diz: “Os microsserviços são modulares, então podemos combinar os serviços existentes de novas maneiras para desenvolver novos serviços. Ao mesmo tempo, é mais rápido porque os desenvolvedores estão trabalhando apenas em elementos pequenos e independentes, o que também reduz o risco de fazer alterações”.

Isso deu à Travelex o tempo e a energia para testar e iterar novos produtos como o Travelex Wire e seu equivalente B2B. Antes, em suas estruturas monolíticas de data center, qualquer novo recurso ou edição com base no feedback do cliente teria de esperar até o lançamento do produto, o que acontecia cerca de oito vezes por ano. Atualmente, a Travelex lança novos programas até 100 vezes por semana, se necessário. “Conseguir ligar servidores em 30 minutos e passar uma tarde testando um novo recurso é muito diferente dos processos de mudança envolvidos em um data center físico”, diz Phelps. “E podemos fazer isso em qualquer lugar do mundo. Graças à AWS, agora temos um data center virtual nos Estados Unidos e na Europa.”

A Travelex está agora ainda mais responsiva às necessidades de seus clientes e pode incorporar novas necessidades mais rapidamente, com microsserviços dedicados a Conheça seu cliente (KYC) e Prevenção à lavagem de dinheiro (AML) que permitem que ela permaneça em conformidade. “Podemos sentar em uma sala com um cliente, integrá-lo ali mesmo, testar e mapear sua jornada pela Travelex e implementar feedback para quaisquer produtos e serviços mais rápido do que jamais conseguimos antes”, diz Phelps.

A Travelex sempre teve uma cultura inovadora e capitalizou a AWS para ajudar suas equipes de produto e TI a encontrar mais tempo para testar, interromper, aprender e separar ambientes. Os engenheiros estão testando o Lambda@Edge, que executa funções de computação sem servidor em resposta a eventos no ponto de presença do Amazon CloudFront para acelerar o desempenho para usuários globais. A empresa também está usando o AWS Lambda como parte de sua nova plataforma de dados, que conterá todos os dados e eventos provenientes de seus clusters do Amazon ECS.

Isso permite aos desenvolvedores executar código sem provisionar ou gerenciar servidores. Phelps diz: “Agora, sempre que precisamos projetar um ambiente, temos a opção de microsserviços ou sem servidor. Em longo prazo, usaremos a opção sem servidor tanto quanto pudermos, porque há menos pilha de tecnologia para gerenciarmos e nossos engenheiros podem se concentrar em nossos clientes”.