Email for payment, wallet and banking-style apps

In a fintech product the email is both a notification and a fraud control. Customers use it to spot activity they did not make, which sets the standard: it must be accurate, timely, consistent and unforgeable-looking.

Regulatory note

This page covers email design. It does not claim that Inboxili satisfies any financial regulation, audit standard or certification. Decide notification requirements and record keeping with your own advisers.

The core set

| Event | Email | Must include | |---|---|---| | Money received or sent | Transaction alert | Amount, direction, counterparty name, time, last digits of account | | Transfer initiated | Confirmation | Amount, reference, expected timing | | Card or payment declined | Notice | Reason category, what to do | | New sign-in or device | Security alert | Time, place, how to lock the account | | Credential changed | Security alert | What changed, how to reverse | | Verification | OTP | Code, expiry, "we never ask for this" | | Statement ready | Notice | Link to the signed-in area, never the statement |

Rules that matter

• No actionable links in alerts. Link to your site root or app. A link that approves or declines something is what phishers imitate.
• Say what you will never do. Add a short fixed line such as "We will never ask for your password or full card number by email."
• Minimum identifiers. Last four digits at most.
• One event, one email. A duplicated alert is alarming, and a missing one is dangerous.

Example: transaction alert with a duplicate guard (Python)

import os

from inboxili import Inboxili, InboxiliError

client = Inboxili(os.environ["INBOXILI_API_KEY"])


def alert_transaction(db, tx):
    # Unique key on transaction id: a replayed ledger event sends nothing.
    if not db.try_claim_alert(tx.id):
        return

    sign = "received" if tx.amount_minor > 0 else "sent"
    amount = f"{abs(tx.amount_minor) / 100:,.2f} {tx.currency}"
    try:
        client.emails.send(
            to=tx.account.owner_email,
            from_email="alerts@yourbank.example",
            from_name="Yourbank Alerts",
            subject="Money {{direction}}: {{amount}}",
            html_body=(
                "<p>You {{direction}} <strong>{{amount}}</strong> on {{when}}"
                " (account ending {{last4}}). Counterparty: {{counterparty}}.</p>"
                "<p>Not you? Open the app and lock your account. We will never ask for your password by email.</p>"
            ),
            text_body=f"Money {sign}: {amount} on {tx.occurred_at:%Y-%m-%d %H:%M} UTC (account ending {tx.account.last4}).",
            template_data={
                "direction": sign,
                "amount": amount,
                "when": f"{tx.occurred_at:%Y-%m-%d %H:%M} UTC",
                "last4": tx.account.last4,
                "counterparty": tx.counterparty_name,
            },
        )
    except InboxiliError as e:
        db.release_alert(tx.id)  # the API rejected it, so nothing was sent
        raise

Ordering and timing

Emails can arrive out of order. Put the transaction time in the message so a later alert for an earlier event reads correctly. Send alerts from a queue that preserves event order per account where possible, and keep an internal log of every alert sent.

Delivery events

A bounced alert means your fraud control is silent for that customer. Show an in-app warning and prompt them to correct their address. For complained, stop optional emails but keep mandatory security notices flowing through another channel.

What Inboxili does not provide

No attachments, CC, BCC or reply-to, and no built-in scheduling. Statements go behind a login, not into email.