A Comprehensive Guide to Rules Change Management with Synctera

Welcome to Rules Strategy with Synctera. The purpose of this document is to provide the rules change management process throughout the lifecycle of your program.

Introduction

Synctera will begin with a rule-based monitoring system by partnering with a transaction monitoring solution provider which includes a default rule set. The default rule set can be configurable and customizable according to your program’s risk appetite during pre-launch and post-launch with the bank’s approval. Following the necessary steps below will ensure a smooth and collaborative alignment on the rules strategy process:

Pre-Launch Fraud Rules Strategy Process:

During implementation, there are several steps to ensure your program will launch with the appropriate rule configuration(s).

• The initial fraud strategy meeting with Synctera’s compliance operations team is scheduled with assistance from an I&O team member (~30 min meeting).

• The initial fraud strategy meeting may consist of a fraud presentation and high-level overview of the rules strategy document.

• Synctera’s Compliance Operations team will share the fraud rules strategy document with your team for review and feedback (Please allow 2-3 business days).

• Synctera Compliance Operations team will respond to the feedback and/or questions within the document (Please allow 3-5 business days for response)

• Synctera will schedule a follow-up meeting for any questions/feedback on any outstanding fraud rule(s) if necessary (~30-45 min meeting).

• Synctera will share a final version of the rules strategy document for your review and confirmation. (Please allow 2-3 business days for final version)

• Upon confirmation, Synctera will submit an approval request to the bank via the information request case on your behalf:

• Purpose of request

• Hard limits approval request

• Per payment type (e.g. ACH, wires, debit card, smartcard)

• Duration (e.g. daily limit for cards)

• Customer type (consumer/business) if applicable

• Amount/Count

• A copy of complete list of the fraud rules strategy

Example of an Information request case:

• The case will be submitted to the bank for approval
• Bank approval is dependent on the rule changes and resources.
• After bank approval, the applicable approved rule modification(s) is then configured, tested and published in the production environment by a member of the Compliance Operations team.
• The completion of the rule configuration(s) will be communicated to the FinTech via the submitted information request case and other applicable communication channels
• The information request case will be marked as “complete”.

Any delay(s) on the rules configuration will be communicated to the FinTech and the I&O team via email. The communication should consists of the reason for delay, the impacted rule(s), status, ETA of resolution*

Post-Launch (Approval Request)

Rules/limit changes can be made at any time during the life of your program. Similar to the pre-launch process, it is critical that the following processes are adhered to in order to have a smooth and successful implementation of the rule changes.

Please submit an Information Request case to the bank within Synctera’s UI with the following information (Please see Synctera’s learn site on step-by-step process on how to create an information request case)

If a transaction triggers a fraud case due to the hard limit being breached, an information request case is NOT required. Please place a note within the fraud case on the validity of the transaction. Synctera’s Ground Control team will assign the case to the bank for review and approval

Step 1: Open in Information Request Case within the UI and select your partnered bank in the “To” dropdown section

Step 2: Create note within the request based on one of the following categories (“Rule Limit Changes” OR “Exception Requests”)

For Hard Limit Changes: (This is the typical notes required in the case if the changes are the same across all your users)

Include the following information in the information request case:

• Hard Limit Change Request (e.g. Daily card spend increase from $1000 to$3000)
• Reason for change request (e.g. the daily average activity of all users have been ~$2500 and there have been a large number of false positive cases due to the current default limit)
• Case example (if applicable)

OR

For Future Exception Requests: (Future Exception requests are for one off scenarios that the user has informed you ahead of time. e.g. one time approval limit increase for a specific user that will be purchasing a car)

Include the following information in the information request case:

• Brief summary of the purpose of the future transaction (e.g. user wants to transfer $51,000 to their BOA account to purchase a vehicle)
• Link to the user’s profile (this can be found in the url within the UI)
• Date of future transaction
• Originating account
• Beneficiary account (if applicable)
• Supporting documents, if applicable (e.g. invoice, statement, etc.)

Steps 3-10:

• Assign the information case to yourself (or team), Synctera’s Compliance team member, and the bank after selecting “Submit Request” button
• Review and analysis of the rule change request to be completed by Synctera’s Compliance Operations team (Estimated Time to complete: 1-2 business days depending on number/complexity of the rule changes)
• If applicable, provide feedback/suggestions within the information request case. Additional meeting if needed.
• Bank approval is dependent on the rule changes and resources. (Estimated time for bank approval: 1 to 3 business days)
• After bank approval, the approved rule change(s) is configured, tested and published in the production environment by Synctera.
• The completion of the rule configuration(s) will be communicated to your team and the bank via the submitted information request case.
• Once configuration is complete, the Compliance team will upload the updated rules strategy document in the information request case for reference.
• Synctera will mark the case as “complete”.

Any delay(s) on the rules configuration will be communicated to the FinTech and the I&O team via email. The communication should consists of the reason for delay, the impacted rule(s), status, ETA of resolution

FAQs

What is needed in the information request case if a user wants to make a transaction that is above the limit for a one-time transaction?

See Exception Requests

How can we escalate an information request case for a user that needs to make the transaction ASAP?

Select “Critical” as the priority when creating the case and inform the Compliance team

We have a select few users in our program that will have different limits than the general users, how can this be accomplished?

We suggest utilizing the Spend Monitoring feature in the UI for those select users. Those select users will be added on the allow list within our Transaction Monitoring platform to prevent the rules from being triggered. Instruction on Spend Monitoring feature can be seen here

Do we still need bank approval if we want to utilize Spend Monitoring for those select users?

Yes, an information request case must be submitted to the bank for approval.

Do we need bank approval if we want to remove a country that is listed in the auto decline list?

Yes, an information request case must be submitted to the bank for approval.

Do we need bank approval if we want to reduce or place further restrictions on specific rules?

No, but a communication to Synctera must be made for such a request.

We’re in the post launch stage now but we will be launching a new product (e.g. Smartcard), do we still need to go over the rules strategy with the compliance team?

Yes. It’s important to understand the rules and limits for the new product in order to avoid a large number of false positives while preventing fraud. An information request case must be submitted to the bank for approval for any rule changes for the new product

What if we are to launch with the default limits, do we need bank approval on the default limits?

No, bank approval is not required if you are launching with the default limits. Unless your default limits align with your program, launching with the default limits may result in large false positives.

Does the bank need to approve every rule changes?

No, the bank only needs to approve hard limits

Where can I submit a ticket if a fraud rule is not working as intended?

Submit a zendesk support ticket on the issue

Do limits include the declined transaction amount and/or count in the total?

Depending on the rule, the declined transaction amount and/or count is not included in the total

I don’t understand a rule or rule(s). Where can I find more information about a rule or multiple rules?

Learn site link can be found here on further information and/or example of a rule or multiple rules

Do I need to submit a zendesk support ticket if I want to increase a hard limit temporarily due to a fraud case?

No. Simply validate the transaction within the fraud case by placing a note and the case will be assigned to the bank for review and approval.

Do I need to submit a zendesk support ticket if I want to increase a hard limit permanently?

No. Your program must submit an information request case TO the bank for review and approval. See information above.