Real-Time Identity Matching
Verifies that the customer connecting the bank account is its legitimate owner by comparing verified identity data with bank account details.
Advanced Data Handling
Manages variations in personal information, such as typos, nicknames, and cultural differences in naming conventions.
Fraud Detection
Identifies and prevents potential fraudulent activities before they occur.
Always Compliant
Embeds regulatory compliance checks into the identity verification process, reducing the compliance burden on your organization.
How Bridge Creates Paykeys
Bridge is Straddle’s connectivity platform that securely links customers’ bank accounts to your application. When a customer connects their bank account through Bridge, a Paykey is generated to securely represent this connection. Here’s how the process works:1
Customer Identity Verification
Before connecting a bank account, the customer is onboarded and their identity is verified using Straddle ID. This ensures compliance with KYC (Know Your Customer) and AML (Anti-Money Laundering) regulations.
2
Bank Account Connection via Bridge
Bridge Widget
Bridge Widget
The customer connects their bank account using the Bridge Widget, an embeddable interface within your application.
Third-Party Tokens
Third-Party Tokens
Alternatively, Bridge accepts existing tokens from providers like Plaid, MX, or Finicity, leveraging customers’ pre-existing bank connections.
Manual Bank Entry
Manual Bank Entry
Paykeys name matching is also possible with manual bank entry.
3
Identity Matching with WALDO
is Bridge’s proprietary algorithm for verifying bank account ownership.
Data Comparison
WALDO compares the customer’s verified identity from Straddle ID with the bank account ownership details retrieved during the bank connection.
Handling Variations
The algorithm accounts for minor discrepancies, such as nicknames, middle names, typos, and cultural naming conventions, to accurately match identities.
Fraud Prevention
By confirming legitimate ownership, WALDO helps prevent fraudulent activities and unauthorized access to bank accounts.
Real-Time Processing
The verification occurs instantly, ensuring a seamless user experience without added delays.
4
Paykey Generation
Unique Identifier Creation
Unique Identifier Creation
A Universally Unique Identifier (UUID) is generated to represent the link between the customer and their bank account.
Hashing and Encoding
Hashing and Encoding
The UUID is hashed using a cryptographic hash function (BLAKE3) to ensure it cannot be reverse-engineered. The hashed value is encoded (e.g., Base64 or URL-safe encoding) to produce the Paykey.
Paykey Structure
Paykey Structure
The result is a secure, unique token (the Paykey) that represents the customer-bank account linkage.
5
Secure Delivery of the Paykey
The Paykey object is securely returned to your application. It includes the paykey, masked bank account details, and the available balance.
6
Storage and Usage
Secure Storage
Your application never has to transmit PII or bank account details to Straddle.
Payment Initiation
The Paykey is used to initiate payments via Straddle’s Payments API. It authorizes payments without exposing sensitive PII or bank account details.
By integrating Bridge and utilizing the WALDO algorithm to create Paykeys, you provide a secure and efficient way to process payments, enhancing both security and user experience.
Paykey Object Definition
The Paykey object represents a secure, tokenized link between a customer and their bank account. It is used to authorize payments without exposing sensitive financial information.Paykey Attributes
Field | Type | Description |
---|---|---|
id | string | Unique identifier for the paykey, generated by Straddle. |
customer_id | string | Unique identifier of the customer associated with this paykey. |
label | string | Human-readable label for the paykey, often including the bank name and masked account number. |
source | string | Method used to create the paykey (e.g., bank_account , plaid , mx , straddle ). |
institution_name | string | Name of the financial institution associated with the paykey. |
status | string | Current status of the paykey (pending , active , inactive , rejected ). |
status_details | object | Additional information about the paykey’s status. |
↳ message | string | A human-readable description of the current status. |
↳ reason | string | A machine-readable identifier for the specific status. |
↳ source | string | Identifies the origin of the status change (e.g., ‘bank_decline’, ‘system’). |
paykey | string | The tokenized paykey value used for transactions. |
bank_data | object | Masked bank account details associated with the paykey. |
↳ routing_number | string | The bank’s routing number. |
↳ account_number | string | The masked bank account number (e.g., “******1234”). |
↳ account_type | string | The type of bank account (e.g., “checking” or “savings”). |
balance | integer | The available balance of the linked account in cents, if available. |
metadata | object | User-defined key-value pairs for storing additional information about the paykey. |
expires_at | datetime | Expiration date and time of the paykey, if applicable. |
created_at | datetime | Timestamp of when the paykey was created. |
updated_at | datetime | Timestamp of the most recent update to the paykey. |
Paykey Status Details
Status | Description |
---|---|
pending | Initial status when the paykey is created and awaiting verification. |
active | Paykey has been verified and is ready for use in transactions. |
inactive | Paykey is no longer active and cannot be used for transactions. |
rejected | Paykey failed verification or was rejected by the financial institution. |
Notes
Notes
- The
account_number
in thebank_data
object is always masked for security reasons. Use the unmasked paykey data endpoint to access the full account number when necessary and authorized. - The
balance
field is only available for certain integration types and may not always be present. - The
source
field indicates the method used to create the paykey, which can affect the available features and verification process. - The
metadata
object can contain up to 20 key-value pairs, each with a maximum length of 40 characters for keys and 500 characters for values. - The
created_at
andupdated_at
fields are automatically managed by Straddle and cannot be modified directly. - The
expires_at
field is only applicable for certain types of paykeys and integration methods.
Example Paykey Object
Using Paykey
Paykeys are used in place of customer and bank account details when creating charges or payouts. Here’s an example of creating a charge using a paykey:Benefits of Paykeys
For Businesses
Reduced Fraud Losses
Prevent unauthorized account use and save on potential fraud-related losses.
Regulatory Compliance
Simplify adherence to KYC and AML regulations.
Operational Efficiency
Automate identity matching, reducing the need for manual reviews.
Improved Customer Trust
Enhance reputation by ensuring secure transactions.
For Customers
Security
Protect customers from unauthorized use of their bank accounts.
Convenience
Eliminate the need for additional verification steps.
Privacy
Ensure personal data is handled securely and used appropriately.
Confidence
Build trust in the platform’s ability to protect financial information.