Mitigating Fraud

Fraud Prevention Strategy

As a bank-holding company and state member bank, Green Dot has a fraud program dedicated to protecting customer finances, detecting and preventing fraud, and verifying individuals who wish to open an account via our Customer Identification Program (CIP). Green Dot implements tools and processes to mitigate identity theft, unauthorized account activity, and other risk-based vulnerabilities, using a combination of both in-house and third-party solutions. To view KYC and IDV Best Practices, click here.

Green Dot manages all fraud functions for BaaS programs, including:

• Establishing and implementing a fraud prevention strategy
• Setting and updating fraud rules: rules may decline suspicious transactions in real-time and, in some cases, place a block on the account and/or card and prompt for additional verification
• Selecting and operating fraud systems; and
• Providing fraud reporting

Customer Identification Program (CIP)

In full compliance with the requirements of the U.S. Patriot Act and Bank Secrecy Act (BSA), Green Dot collects, at a minimum, the following information from all potential accountholders prior to activating an account:

• Name
• Date of Birth
• Residential Address
• Social Security Number and ITIN

In addition to regulatory requirements, Green Dot has developed and implemented an enhanced CIP process with additional verification tools, including conducting multiple identity checks and collecting mobile number and e-mail information, to assist in identifying and monitoring any suspicious identities or behavior.

Fraud Reporting

During the implementation phase, Green Dot will provide you with a fraud reporting template which will set forth the regular reporting you will receive on aggregate fraud trends and metrics.

If you would like further information on Green Dot’s fraud operations, please speak to your program manager.

Post-Registration Negative Match

During account registration, Negative Match processing is performed on the customer’s SSN, phone Number, email, and address attributes. After registration, when the account has already passed CIP and is active, if the customer changes any of those attributes (except SSN, which cannot be changed after an account has already been opened), no further Negative Match processing occurs. This is when fraud can and does occur.

To mitigate fraud, when a customer attempts to change a phone number, an email, or an address after an account is active, the Fraud service checks the customer’s change request against Negative Match. If any change attribute is on Negative Match, the Fraud service triggers Core, Gateway, and other upstream layers to perform the following in real-time:

• Decline the change request.
• Display, on the customer’s device, a generic decline message indicating the request was declined and that the account is now temporarily blocked pending additional verification.
• Lock the account with a "manual" cure.

Next, CRM creates a Fraud Referral Case for the FraudOps team, which performs the following:

• Reviews and resolves the case within a two-business day SLA, at which time they can decide whether to keep the account blocked, unblock it, prompt additional cure, etc.
• Applies any desired account status change via CRM or Strike3.

Finally, Status Reason Code “FR-POTF” (Potential fraud) is logged in the database and passed to CRM. This makes agents and analysts (i.e., the BSA/AML team) aware of the post-reg neg match trigger in case they would like to conduct any further reviews.

Fraud Status Reason Code

If an error occurs during Negative Match processing, the following status reason is returned.

• statusReasonCode = FR-POTF
• Description = Potential Fraud

Response

{
  "responseDetails":[
    {
      "code":5,
      "subCode":110,
      "description":"Negative Decline",
      "url":"http://tbd"
    }
  ]
}

Fraud State Vs. Features Matrix

📘

Account status reasons with an asterisk are deprecated.

If Status = Normal: All features are allowed

1. If Status = Pending or Locked: No state changing features are allowed.
   1. Note: If there is a cure, then KYCGates may still be used. When an account is locked, access to the retrieval APIs is still allowed; however, guidance should be sought from a partner’s onboarding contacts.
2. If Status = Closed: See Closed Accounts for details.
3. If Status = Restricted: See below tables.

Money Movement Features & Statuses

Non-Money Movement Features & Statuses

Rules for Determining Statement Dates

The Statement Period runs from the Billing Cycle Date to the day prior to the Billing Cycle Date of the following month.

If the account was activated between the 1st and 28th of a month, the Billing Cycle Date is based on the date the account was activated.

If the account was activated on the 29th, 30th or 31st of a month, then the Billing Cycle Date is the 1st.

The statement period is based on the end date of the statement.

Statements are made available 3 calendar days after the Billing Cycle Date. This is to allow enough time for any posts to be reconciled.

Examples

If an Account was Activated on 8/24 then:

Billing Cycle Date is the 24th

September Statement would run from Aug. 24th to Sept. 23rd

September Statement would be available, and the notification would be published on Sept. 27th

If an Account was Activated on 8/29 then:

Billing Cycle Date is the 1st

August Statement would run from Aug. 29th to Aug 31st

September Statement would run from Sep. 1 to Sep 30th.

September Statement would be available, and the notification would be published on Oct. 4th

eStatement Logo Requirements

📘

To enable an eStatement logo, you must provide Green dot with a copy of the desired logo to be configured.

Green Dot Google Pay Email Example

Device Statuses

Statuses include the following:

active

suspended

deactivated

deleted

inactive

resume

tokenizationException

replacement

eWallet - Initial Provisioning Flow

eWallet - Status Update Flows