Primeiros passos com o Flowker

As operações financeiras envolvem várias etapas, aprovações e verificações externas. Gerenciar isso à mão leva a erros, atrasos e lacunas de compliance. O Flowker deixa você definir esses processos uma vez como workflows e executá-los de forma consistente, com registros de execução por etapa e visibilidade em tempo real. Para as instruções técnicas de configuração, veja o Início rápido técnico.

​

Como o Flowker funciona

---

Você começa explorando quais integrações estão disponíveis, conecta-as ao seu ambiente, define um workflow que modela o seu processo de negócio e então o executa. Cada execução deixa um registro rastreável e disponível para inspeção pela API.

​

O que você pode automatizar

---

O Flowker foi feito para processos financeiros de várias etapas que exigem confiabilidade, rastreabilidade e integração com serviços externos.

​

Orquestração de pagamentos

O desafio: um pagamento envolve várias etapas: validação, roteamento para o provedor certo, confirmação e notificação. Quando isso é feito à mão ou por integrações espalhadas, as falhas passam despercebidas e a conciliação fica dolorosa. Como o Flowker resolve: defina um workflow que coordena todo o ciclo de vida do pagamento:

1. Gatilho: uma nova requisição de pagamento chega pela API ou por webhook.
2. Validar: verifique se os dados do pagamento estão completos e se a conta tem saldo suficiente.
3. Rotear: escolha o provedor de pagamento adequado com base no valor, na moeda ou no trilho (Pix, TED, SWIFT).
4. Confirmar: chame o provedor e espere a confirmação.
5. Notificar: envie um evento de confirmação ao cliente e atualize o ledger.

Para as chamadas de executor, você configura o comportamento de nova tentativa por nó. Por padrão, as chamadas POST e PATCH rodam uma vez, a menos que você ative as novas tentativas no nó. O Flowker não deduplica o efeito colateral no provedor durante as novas tentativas: a Idempotency-Key da execução deduplica execuções do Flowker, não as requisições de saída ao provedor. Ative as novas tentativas em um nó POST ou PATCH apenas quando a operação do provedor for idempotente. Você também pode ativar quando o provedor documenta uma chave de negócio estável e a aplica de forma atômica. Envie essa chave em um header como chave de idempotência em cada tentativa. Caso contrário, mantenha as novas tentativas desabilitadas no nó. O Flowker registra cada nó de executor, condicional e ação executado para conciliação e revisão.

​

Validação antifraude

O desafio: as verificações de fraude devem acontecer antes do processamento da transação. Elas envolvem serviços externos, lógica de pontuação e limiares diferentes conforme o tipo de transação. Deixar essa lógica fixa no código cria pesadelos de manutenção. Como o Flowker resolve: defina um workflow pré-transação que roda as verificações de fraude antes de qualquer coisa chegar ao ledger:

1. Gatilho: uma nova transação chega.
2. Enriquecer: colete o histórico do cliente, os dados do dispositivo e a geolocalização dos sistemas internos.
3. Pontuar: chame um ou mais provedores de detecção de fraude e colete as pontuações de risco.
4. Decidir: aplique as regras: se a pontuação estiver acima do limiar, bloqueie. Se estiver no limite, marque para revisão. Se estiver limpa, aprove.
5. Agir: siga com a transação ou avise o time de compliance.

Todas as decisões são rastreáveis. Você pode ajustar os limiares e adicionar novos provedores sem mudar a lógica central.

​

Onboarding de clientes

O desafio: o onboarding de um novo cliente exige verificação de identidade, validação de documentos, verificações de AML/KYC e criação de conta. Essas etapas envolvem vários provedores externos e exigências regulatórias que variam por jurisdição. Como o Flowker resolve: defina um workflow de onboarding que automatiza todo o processo:

1. Gatilho: um novo cadastro de cliente chega.
2. Verificar identidade: chame um provedor de KYC para validar os documentos e a identidade do cliente.
3. Checar compliance: rode a triagem de AML contra listas de sanções e bases de PEP.
4. Avaliar risco: aplique as regras internas de risco com base no perfil do cliente, na jurisdição e no histórico de transações.
5. Criar conta: se todas as verificações passarem, crie a conta do cliente no sistema.
6. Notificar: envie um e-mail de boas-vindas ou avise o gerente de relacionamento se for preciso uma revisão manual.

O resultado de cada etapa determina a próxima ação. Se uma verificação falha, o workflow para e registra o resultado de etapa que explica o motivo.

​

Workflows de aprovação manual

O desafio: algumas operações (transferências de alto valor, mudanças de limite de crédito, encerramentos de conta) exigem aprovação humana. Mas montar fluxos de aprovação com notificações por e-mail, timeouts e caminhos de escalonamento é complexo e sujeito a erros. Como o Flowker resolve: defina um workflow que chama um serviço externo de aprovação por um nó de executor:

1. Gatilho: uma requisição de transferência de alto valor chega.
2. Avaliar: verifique o valor, o perfil de risco do cliente e as políticas internas.
3. Pedir aprovação: chame um serviço externo de aprovação (gestor, responsável por compliance) por um nó de executor.
4. Decidir: um nó condicional avalia a resposta da aprovação.
5. Agir: se aprovada, siga com a transferência. Se recusada, cancele e avise quem pediu.

Você pode definir aprovações em vários níveis encadeando nós de executor que chamam o seu serviço de aprovação em cada nível.

​

Principais recursos

---

• Validação pré-ledger: coloque cada verificação antes do nó de lançamento no seu grafo e use nós condicionais com arestas de sourceHandle correspondente para rotear até o lançamento apenas os resultados aprovados.
• Registros de execução por etapa: os resultados da execução registram status, duração, saída e erro de cada nó de executor, condicional ou ação executado. Os nós de gatilho começam o percurso do grafo e não criam registros de etapa de execução.
• Integrações com provedores: conecte a motores antifraude, provedores de KYC, processadores de pagamento e qualquer serviço baseado em HTTP.
• Ramificação condicional: um nó condicional escolhe a aresta de saída cujo sourceHandle corresponde ao resultado dele, então você pode rotear a execução com base nos resultados das etapas, nos valores, nas pontuações de risco ou em qualquer campo de dados.
• Execução idempotente: reutilizar uma Idempotency-Key devolve a execução existente do Flowker em vez de criar outra. A execução direta exige uma chave não vazia. O header do webhook é opcional.
• Monitoramento de execuções: leia o status da execução pela API enquanto um workflow roda. Recupere os resultados da execução, com os resultados das etapas, depois que ela chega a um estado terminal.

​

Próximos passos

---