Starter
$1,250/month
- Included MAU
- 5,000 MAU
- Best for
- Fintechs piloting step-up authentication or account recovery
Native Biometrics
In developmentEnroll 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
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
What's in the box
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 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.
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.
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.
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.
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
Using `@swepay/biometrics-core` against the Native Biometrics API. Most apps enroll once per user, then verify on every step-up event afterward.
Mount `<FaceEnroll />` (or call the client directly) once per user, right after signup or at the point your risk policy requires strong identity proof.
Open a verification session whenever your risk policy calls for proof-of-presence — a new device, a high-value transfer, a password reset.
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.
`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
Facial data is sensitive personal data under LGPD (art. 5º, II). Native Biometrics is built to minimize what it retains.
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.
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.
All biometric processing happens in `sa-east-1` (São Paulo). Nothing crosses the border for enrollment or verification.
`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
Billed entirely through AWS Marketplace — no separate invoice. Pick a monthly plan for predictable included volume, or pay per dimension if usage is irregular.
Every plan below includes a bundle of `bio_mau`; usage beyond the plan, or usage outside a plan entirely, is billed per dimension.
| Dimension | Description | Price |
|---|---|---|
bio_enrollFace enrollment | Completed face enrollment (one per user) | US$ 0.25 |
bio_challengeVerification / recovery | Completed verification or account-recovery challenge | US$ 0.10 |
bio_mauMonthly active user | Enrolled MAU, includes up to 3 verifications | US$ 0.30 |
Priced by monthly active user (MAU) — a user who completes at least one enrollment or verification in the billing month.
$1,250/month
$12,400/month
$45,000/month
Talk to engineering for an AWS Marketplace Private Offer with custom volume and a contractual SLA.
Talk to engineering→Which one do I need?
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.
| Criterion | Native Biometrics | Native KYC |
|---|---|---|
| Core question | Is this the same person who enrolled? | Who is this person, and does their document prove it? |
| Typical moment | Step-up authentication, account recovery, repeat verification | Onboarding a new customer for the first time |
| Input | Live face capture only | Document (RG/CNH/CIN/passport) + live face capture + CPF |
| Output | Signed assertion (JWS), any IdP verifies offline | Explainable verdict (approved/review/rejected) + evidence chain |
| Sanctions/PEP screening | No | Yes (OFAC, UN, EU, CEIS/CNEP/PEP) |
| What's stored | Face vector only, in your tenant's Rekognition collection | Evidence 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
Straight answers to the questions that come up most before a security or compliance review.
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`.
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.
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.
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`.
Yes. `DELETE /v1/enrollments/{userRef}` removes the indexed face immediately. Data-subject requests: [email protected], subject `DSR`.
Subscribe, get JWT credentials, run your first enrollment today.
Subscribe to Native BiometricsAsk engineering before you subscribe — API shape, assertion verification, or how this fits with NativeGuard or Passly.
Email engineeringFor platforms with MAU above 300,000, or that need a dedicated onboarding session before rolling out to production.
Talk to engineering