Make every financial moment feel immediate and trustworthy.
Deliver verification codes, transaction alerts, risk notifications, and account updates through a resilient messaging layer with clear delivery records.
When the message is late, the financial action stops.
In financial products, messaging is part of the transaction. Delay blocks access, missing alerts weaken trust, and incomplete records make investigation harder.
Access waits on a message
An OTP or verification link that arrives late turns a simple login into abandonment, repeated requests, and support work.
Risk needs an immediate response
A suspicious transaction alert is valuable only when the customer can understand it and act before the risk spreads.
Every send must stand up to scrutiny
Operations and compliance teams need to know what was sent, through which route, when it changed state, and why it failed.
Meet Sent: the delivery layer between a financial event and customer action.
Your system creates the authentication, payment, risk, or account event. Sent validates the message request, routes delivery, and returns a traceable status for every attempt.
Keep access, activity, and risk communication moving.
The large cards focus on verification and transaction trust. The compact cards cover risk, account visibility, and reachability.
Deliver OTPs and verification codes
Send short-lived codes through reusable templates with code and expiry variables, a defined channel order, and status tracking for every attempt.
Make transaction alerts actionable
Confirm payments, card activity, transfers, withdrawals, and account changes with enough context to recognize the event and a safe path to act.
Warn before risk spreads
Send suspicious-activity and unusual-login alerts from your risk system the moment investigation or customer confirmation is needed.
Keep balances and obligations visible
Surface low balance, payment due, limit, loan, and subscription events without forcing the customer to search for them.
Reach users when one route is unavailable
Define channel fallback for critical messages so a missing app or unsupported device does not silently block the workflow.
Engineer financial messaging for resilience and traceability.
Build a resilient verification path
Keep code generation and attempt rules in your authentication system, then use Sent for template delivery, channel routing, status events, and fallback. This separation prevents the messaging layer from becoming the source of authentication truth.
Give operations evidence, not guesswork
Store Sent message IDs and use signed webhook events to follow queued, routed, sent, delivered, read where supported, failed, and received states. Failure reasons point the team toward the correct recovery path.
Security controls for messages that move money and access.
Keep sensitive financial data out of message content, use masked identifiers, and send customers into authenticated product surfaces for protected actions.
Separate required account communication from marketing, maintain customer preferences, and apply opt-out and country-specific messaging requirements.
Keep API keys server-side, verify webhook signatures, rotate credentials by environment, and use idempotency for mutation requests.
Frequently asked questions
Sent delivers the messages a financial product depends on: one-time passcodes, payment and transfer confirmations, card activity, suspicious-activity alerts, low-balance warnings, and payment-due reminders. Your banking, payments, or risk system triggers each message, and Sent routes it over SMS, WhatsApp, or RCS with a delivery status for every attempt.
No. Your authentication system creates, stores, and checks each code, and sets its expiry and attempt limits. Sent receives only the code and the other template variables, delivers the message, and reports what happened to it. This keeps your authentication system the single source of truth for whether a login succeeds.
Every Sent message has a unique ID linked to its full history: each status change with a timestamp, the channel and route used, and a reason code if it failed or was blocked. Your team can retrieve the full message text and price for any message ID through the API. The same history is also visible in the dashboard's activity log.
Only what the customer needs to recognize the event, such as a masked card number and an amount. Send them into your app for anything protected. Keep in mind that Sent's delivery webhooks include the message text, so anything you put in a message also reaches your webhook systems.
On WhatsApp and RCS, Sent reports when the customer reads the message. On SMS, it reports delivery. If the alert asks a question, such as "Was this you? YES / NO", the customer's reply or tapped button reaches your risk system as a reply event, so you can block a card or close the case.
Sent is SOC 2 Type II certified, and data is stored in AWS regions in the US and EU. For PCI requirements, data-residency needs, or compliance documentation, contact Sent directly; the public docs don't list a PCI certification.
No. In Sent, an opt-out is one setting per customer, so STOP blocks every later message on every channel, including account and security alerts, until the customer replies START. Only the confirmation of the STOP itself is still sent. If you are obliged to reach opted-out customers, plan another route such as email or in-app notices.
One API. Every channel.
Contact Sales