Review a financial website sign-up form

Our recommendation, up front. We make Proxy Mail QA, so we’re not neutral. For a bank, lending, investing, insurance or payments sign-up, we recommend it for a narrow part of the review: the emails (verification, email codes and password reset), test accounts of an exact age and country for your eligibility rules, and awkward names and passwords for the form’s fields. It can’t do the parts that make financial sign-up hard: SMS codes, identity checks (KYC), payments and bank linking. It isn’t a compliance review or legal advice, and it hasn’t had an independent audit such as SOC 2 yet. Use it on staging, with made-up test data only.

What’s different about a financial sign-up

• Eligibility. Usually 18 or over, and only in the countries you’re licensed in.
• Real names. The name on the account has to match an ID document later, so the form must take names as people actually have them.
• Stronger sign-in. Longer passwords, a second factor, and in some places strong customer authentication by law.
• Emails worth faking. Your brand is a phishing target, so your emails need to be clearly genuine, and your links need to go only to your domain.
• Nothing given away. The form shouldn’t confirm whether someone already has an account.
• A record. Someone will ask how sign-up was tested.

What Proxy Mail QA helps you check

Age and country rules

create_address makes a test persona of an exact age (under18, turns18tomorrow, turned18today, adult, over21) and a country (such as GB, DE or US), with a date of birth and country that match. Check:

• Someone under 18 is refused, with a clear reason and no account left half made.
• Someone who turns 18 tomorrow is refused today; someone who turned 18 today is accepted.
• Each country you don’t serve is refused, and each you do gets the right terms.

The age-and-region-testing skill in the Proxy Mail QA plugin runs these and tags each account for the next run.

Names as people really have them

get_name_variants gives names to accept (O'Brien, Smith-Jones, Søren, Łukasz, 李, محمد, प्रिया), ones to reject (empty, only spaces, over the maximum) and HTML or SQL that must be stored as text. A form that refuses D'Angelo either turns a real customer away, or makes them type a name that won’t match their ID later.

Password policy

Test the rules you’ve chosen with get_password_variants: exactly the minimum and maximum, one under, one over, each kind of symbol, a space inside, and, when the maximum is over 72, two passwords that share their first 72 bytes (an app that hashes with bcrypt reads only the first 72, so the second mustn’t sign in as the first). For which rules to choose, see How long should my registration form password be?

Emails that are clearly genuine

check_email checks each email that arrives:

• SPF, DKIM and DMARC pass, so inboxes can tell your mail from a fake.
• The verify or reset link goes to your domain (expect_host), not to production from staging, and no link goes to localhost or plain http.
• A stated expiry. The check warns when a code or link email doesn’t say when it stops working. Whether the server keeps to what it says is yours to test: wait past the time, then try the code.

Wording that gives nothing away

• Sign up with an address that’s already registered: the page should say the same as for a new one, such as “Check your email”.
• Ask for a password reset for an address that has no account: the page should say the same as for one that does. expect_no_email or count_emails shows what, if anything, was sent.

Links and codes that can’t be reused

The auth-regression-pack skill (or the auth_regression_pack prompt) opens a verification or reset link a second time, and an older reset link after a newer one was sent. Both should fail. wait_for_code with unused: true gets a second code without picking up the first again.

A record of the test

start_run and finish_run give a Markdown report of each session for the pull request or your change record, and the app’s QA report downloads as CSV or prints to PDF.

What Proxy Mail QA can’t do

Before you use it at a financial company

• Test data only. Personas are fictional. Never put a real customer’s name, date of birth or address into a test account.
• Where data is kept. Test mail and accounts are stored in the United States (AWS us-east-2), encrypted at rest by the host but not end to end. Treat test inboxes as test data.
• What isn’t there yet. Two-factor sign-in for Proxy Mail QA accounts, and an independent security audit or certification such as SOC 2. If your security team requires either for test tools, check the security page for the current state first.
• Staging, not live. It’s for apps you build or are allowed to test. A few big services, including PayPal, Coinbase and Binance, are blocked outright.
• Your email provider must send to any address on staging. In sandbox or test mode, such as Amazon SES before production access, it only sends to addresses you’ve verified.

A prompt for your agent

With Proxy Mail QA connected in Qoder (Marketplace):

Review the sign-up at https://staging.acme-bank.dev/open-account with Proxy Mail QA,
for an account that must be 18 or over and in GB or IE. Start a run.
1. Sign up as an adult in GB and finish the email verification. check_email with
   expect_host: staging.acme-bank.dev.
2. Try ages under18, turns18tomorrow and turned18today, and country DE. Each should be
   refused before an account exists, except turned18today.
3. Try get_name_variants in the name fields and get_password_variants with the password
   field's limits. Use a plus tag on the address for each new account.
4. Sign up again with the first address, and request a reset for a new address that
   has no account: the page should say the same as for a real one.
5. Open the verification link a second time: it should fail.
Stop at any SMS, ID or payment step and tell me it's there. Finish the run and give me
the report.

More detail: age-restricted content, password reset testing and unusual names and passwords.