The Swepay platform
Swepay builds the layers regulated Brazilian fintechs use to operate. Today: mTLS certificates in production. In active development: identity, passwordless, transactional email. One stack, four products, working as one.
Why a platform
Most Brazilian fintechs build their security and identity stack the same way: pick a vendor for each layer, write glue code to connect them, and maintain that glue code forever. It works until it doesn't.
Before
Each vendor: its own API model, its own LGPD interpretation, its own audit format, its own roadmap.
After
Shared identity model. Shared audit trail. Shared regulatory posture. One contract, one roadmap, one vendor relationship.
The cost of fragmentation isn't the sum of the vendor invoices. It's the connective tissue that rots.
The architecture
We don't build a platform top-down. We build product by product, each one solving a real problem a Brazilian fintech faces when it hits regulatory scale. Each layer ships when it's ready, with the status visible at all times.
Machine Identity & mTLS
REST API for issuing and managing mTLS certificates. Built for fintechs authenticating dozens to hundreds of B2B partners. CRL and OCSP managed, audit log included, integration ready with the rest of the Swepay stack.
Identity & Access
Multi-realm OIDC/OAuth2 identity server for fintechs that need a managed alternative to Keycloak. Currently in technical validation, we're building toward production readiness with real internal workloads first, external customers second.
Passwordless Authentication
FIDO2/WebAuthn passwordless authentication API for mobile apps. Designed for fintechs that need strong customer authentication without adding user friction. Architecture currently under review with AWS.
Transactional Communication
Transactional email API for regulated services. Designed from the start for deliverability, auditable trail, and Brazilian residency by default, not retrofitted for compliance.
Integration by design
Buying four products from one vendor is not a platform. Coexistence is a platform. Here's what coexistence looks like in practice.
By design, Native Guard issues OAuth2 tokens bound to the mTLS certificate emitted by CA Manager. When your fintech's API receives a request, it knows the caller's identity (from the token) and proves the caller controls the private key (from mTLS). This integration is built into the platform architecture today and will be available end-to-end when Native Guard reaches production.
When Native Email sends a transactional message, the send is registered with the sender's identity from Native Guard. When an auditor asks 'who sent this email,' you get a real answer in seconds, not a SQL hunt across three vendors.
Your finance team negotiates with one entity. Your compliance team reviews one DPA. Your platform team reads one set of docs. The savings here aren't theoretical, ask any fintech that has renegotiated its full vendor stack at once.
Technical foundation
We make conservative technical choices on purpose. Boring infrastructure is the kind that survives a regulatory audit.
Every endpoint carries an explicit version path (/v1/, /v2/). Breaking changes ship on a new version with a deprecation window, your existing integration keeps working. The OpenAPI spec is the contract you can rely on through audit cycles.
Infrastructure runs in São Paulo. Data residency is not a configuration toggle, it's the default. Latency budgets are calibrated for Brazilian workloads.
CA Manager is sold through AWS Marketplace. Your AWS bill includes the line item; no separate vendor invoice, no separate procurement cycle. When you scale, billing scales with you, not against you.
Every API call leaves an audit record. Logs are immutable, retained per your plan, and queryable. When the auditor asks for evidence, you have it.
Native Guard is the identity source of truth for the platform. CA Manager validates against it. Native Email authenticates against it. When Native Guard reaches production, this becomes a single identity chain from machine to message.
Built for Brazil
Data subject rights, retention policies, and legal basis are part of every product's foundation. We document the legal basis for processing per endpoint, expose subject right APIs where they apply, and design retention so it can be configured per regulatory context.
Swepay does not issue certificates for Brazilian regulated infrastructure. When you need them (for SPB, for connections to specific regulated systems), you obtain those from established Brazilian providers. Our products integrate with those certificates as consumers when relevant. Issuance is not our scope.
Every Swepay service runs in São Paulo. No data transits outside Brazil by default. When you need a Data Processing Agreement, ours assumes Brazilian residency, not a derogation of it.
Subscribe via AWS Marketplace for self-serve, or talk to engineering for volume contracts.
See CA ManagerFive-minute quickstart, full API reference, and architecture details.
Go to developersTalk to engineering directly. We'll walk through your scenario and what's available today vs. in development.
Talk to engineering