Native Biometrics

In development

A facial identity API any identity provider can trust.

Enroll a reference face, verify it on demand, and get back a signed assertion your backend — or NativeGuard, or Passly, or any IdP you already run — can verify offline. Only the face vector is stored, inside your tenant's Rekognition collection; the image itself never touches disk, log, or trace.

The use case

Prove it's the same person, without owning face recognition.

Fintechs that need step-up authentication, account recovery, or a capture component for onboarding all hit the same build-vs-buy decision: Amazon Rekognition Face Liveness is the easy part — assertion signing, replay protection, per-tenant data isolation, and an interface any IdP can consume are the hard part.

Native Biometrics does the hard part. Enroll a user's reference face once; verify against it as many times as your risk policy calls for — a new device, a high-value transfer, a password reset.

Every successful verification returns a JWS compact assertion signed with ES256 via AWS KMS. Your backend — or any IdP, including ones Swepay didn't build — verifies it offline against a public JWKS endpoint. No shared session, no proprietary SDK requirement on the verifying side.

Native Biometrics is a standalone product: it works the same way whether or not you also run NativeGuard or Passly. It integrates natively with both — step-up by risk in NativeGuard, the capture component in Passly — but neither is a prerequisite.

Where Native Biometrics fits in your stack

Your appNative Biometrics APIRekognition · KMS (ES256)sa-east-1Your backend or IdPNativeGuard · Passly · any IdPFACE VECTORS ONLY — NEVER A RAW IMAGE

What's in the box

Enrollment, verification, and a portable assertion.

Enrollment and verification via REST or SDK

Call `/v1/enrollments` and `/v1/verifications` directly, or drop in `@swepay/biometrics-react`'s `<FaceEnroll />` and `<FaceCapture />` components — both wrap AWS Amplify's Face Liveness UI so you don't build camera capture from scratch.

A signed assertion any IdP can verify

A successful verification returns a JWS compact token (ES256, signed via AWS KMS) with `sub`, `tenant_id`, `decision`, and confidence scores as claims. Verify it offline against `GET /.well-known/jwks.json` — no callback to Swepay required.

Native integration with NativeGuard and Passly

NativeGuard can call Native Biometrics for step-up authentication triggered by risk signals; Passly uses the same capture SDK for its onboarding flow. Both integrations are native, neither is required to use Native Biometrics on its own.

Face vectors only, never an image

Only the face vector lives in your tenant's Rekognition collection. No raw image is ever written to DynamoDB, logs, or traces — at enrollment, at verification, or during account recovery.

Account-recovery assertion

The same verification flow doubles as an account-recovery factor: prove it's the same person who enrolled, without a support-desk phone call or a password-reset e-mail that can be phished.

sa-east-1 data residency

Rekognition Face Liveness and SearchFacesByImage both run in `sa-east-1` — the only AWS region where the two coexist — so biometric data doesn't leave Brazil.

From zero to a verified user

Three calls: enroll, verify, trust the assertion.

Using `@swepay/biometrics-core` against the Native Biometrics API. Most apps enroll once per user, then verify on every step-up event afterward.

  1. 0. Enroll a reference face

    Mount `<FaceEnroll />` (or call the client directly) once per user, right after signup or at the point your risk policy requires strong identity proof.

    Requestts
    import { BiometricsClient } from "@swepay/biometrics-core";
    
    const client = new BiometricsClient({
      apiBaseUrl: "https://api-biometrics-hml.swepay.com.br", // illustrative — no public host yet
      getAccessToken: () => getCurrentUserAccessToken(),
    });
    
    const enrollment = await client.createEnrollment({ userRef: "user_123" });
    const completion = await client.completeEnrollment(enrollment.enrollmentId);
    Responsejson
    {
      "status": "enrolled",
      "livenessConfidence": 98.4,
      "attemptsRemaining": null
    }
  2. 1. Verify a face on a step-up event

    Open a verification session whenever your risk policy calls for proof-of-presence — a new device, a high-value transfer, a password reset.

    Requestts
    const verification = await client.createVerification({ purpose: "login" });
    const decision = await client.completeVerification(verification.verificationId, {
      livenessSessionId: verification.livenessSessionId,
    });
    Responsejson
    {
      "decision": "approved",
      "livenessConfidence": 98.1,
      "similarity": 96.4,
      "assertion": "eyJhbGciOiJFUzI1NiIsImtpZCI6IjIwMjYtMDktMDEifQ..."
    }
  3. 2. Verify the assertion on your backend

    Any backend — yours, NativeGuard, or a third-party IdP — fetches the public JWKS once, caches it, and verifies the JWS offline. No call back to Native Biometrics on the hot path.

    Requestbash
    curl https://api-biometrics-hml.swepay.com.br/.well-known/jwks.json
    Responsejson
    {
      "keys": [
        { "kty": "EC", "crv": "P-256", "kid": "2026-09-01", "use": "sig", "x": "...", "y": "..." }
      ]
    }

`api-biometrics-hml.swepay.com.br` above is illustrative — Native Biometrics has no deployed public host yet (backend routes are implemented; onboarding onto the Marketplace Subscription Hub is pending). Full SDK reference: `@swepay/biometrics-react` and `@swepay/biometrics-core`. Technical questions: [email protected].

Security & compliance

What we store, and what we never do.

Facial data is sensitive personal data under LGPD (art. 5º, II). Native Biometrics is built to minimize what it retains.

Legal basis: fraud prevention

Processing relies on LGPD art. 11, II, "g" — fraud prevention and identity-holder security. Native Biometrics does not process biometric data for any other purpose.

Only the vector is stored

The face vector lives in an Amazon Rekognition collection scoped to your tenant. The raw image is used in memory for the duration of the request and discarded — never written to DynamoDB, S3, application logs, or distributed traces.

Data residency: sa-east-1

All biometric processing happens in `sa-east-1` (São Paulo). Nothing crosses the border for enrollment or verification.

Deletion on request

`DELETE /v1/enrollments/{userRef}` revokes an enrollment and removes the indexed face — the LGPD deletion trail for a data-subject request. Security and DSR requests: [email protected] (subject `DSR`).

Pricing

Usage dimensions, plus a monthly plan with included volume.

Billed entirely through AWS Marketplace — no separate invoice. Pick a monthly plan for predictable included volume, or pay per dimension if usage is irregular.

Usage dimensions

Every plan below includes a bundle of `bio_mau`; usage beyond the plan, or usage outside a plan entirely, is billed per dimension.

DimensionDescriptionPrice
bio_enroll
Face enrollment
Completed face enrollment (one per user)US$ 0.25
bio_challenge
Verification / recovery
Completed verification or account-recovery challengeUS$ 0.10
bio_mau
Monthly active user
Enrolled MAU, includes up to 3 verificationsUS$ 0.30

Monthly plans

Priced by monthly active user (MAU) — a user who completes at least one enrollment or verification in the billing month.

Starter

$1,250/month

Included MAU
5,000 MAU
Best for
Fintechs piloting step-up authentication or account recovery
Subscribe

Growth

$12,400/month

Included MAU
62,000 MAU
Best for
Products rolling biometrics out to their full active base
Subscribe

Scale

$45,000/month

Included MAU
300,000 MAU
Best for
Platforms authenticating hundreds of thousands of users monthly
Subscribe

Above 300,000 MAU?

Talk to engineering for an AWS Marketplace Private Offer with custom volume and a contractual SLA.

Talk to engineering→

Which one do I need?

Native Biometrics vs. Native KYC

Independent products (ADR-0003) that solve different problems and integrate well together. Most fintechs start with whichever matches the moment: onboarding a new customer, or re-verifying one they already know.

CriterionNative BiometricsNative KYC
Core questionIs this the same person who enrolled?Who is this person, and does their document prove it?
Typical momentStep-up authentication, account recovery, repeat verificationOnboarding a new customer for the first time
InputLive face capture onlyDocument (RG/CNH/CIN/passport) + live face capture + CPF
OutputSigned assertion (JWS), any IdP verifies offlineExplainable verdict (approved/review/rejected) + evidence chain
Sanctions/PEP screeningNoYes (OFAC, UN, EU, CEIS/CNEP/PEP)
What's storedFace vector only, in your tenant's Rekognition collectionEvidence chain (scores, statuses) — no image, no template

Need both? Subscribe to each independently on AWS Marketplace — there's no bundled SKU, and no requirement to run one to use the other.

Frequently asked

Before you integrate.

Straight answers to the questions that come up most before a security or compliance review.

Do you store my users' photos?

No. Native Biometrics never persists a raw image — not at enrollment, not at verification, not during account recovery. Only the face vector is stored, inside an Amazon Rekognition collection scoped to your tenant, in `sa-east-1`.

Does Native Biometrics require Native KYC, or the other way around?

No. Both are independent products — subscribe to one, both, or neither. Native Biometrics answers "is this the same person who enrolled"; Native KYC answers "who is this person, and does their document prove it." See the comparison below.

Can I use the signed assertion with an identity provider Swepay didn't build?

Yes. The assertion is a standard JWS (ES256), verifiable offline against `GET /.well-known/jwks.json` (RFC 7517). Any IdP that can verify a JWT signature can consume it — NativeGuard and Passly do, and so can your own backend.

What happens if liveness or face match fails?

The verification or enrollment returns `rejected` or `retry` — never a silent pass. `retry` means the same session can be resumed (for example, if the liveness capture was inconclusive); `rejected` means the user needs a new session. Nothing gets an assertion unless the decision is `approved`.

Can a user opt out or have their biometric data deleted?

Yes. `DELETE /v1/enrollments/{userRef}` removes the indexed face immediately. Data-subject requests: [email protected], subject `DSR`.

Two ways to start.

Technical questions first?

Ask engineering before you subscribe — API shape, assertion verification, or how this fits with NativeGuard or Passly.

Email engineering

Volume plans and custom integration

For platforms with MAU above 300,000, or that need a dedicated onboarding session before rolling out to production.

Talk to engineering