​
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 1000to1000 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

See Exception Requests
Select “Critical” as the priority when creating the case and inform the Compliance team
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
Yes, an information request case must be submitted to the bank for approval.
Yes, an information request case must be submitted to the bank for approval.
No, but a communication to Synctera must be made for such a request.
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
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.
No, the bank only needs to approve hard limits
Submit a zendesk support ticket on the issue
Depending on the rule, the declined transaction amount and/or count is not included in the total
Learn site link can be found here on further information and/or example of a rule or multiple rules
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.
No. Your program must submit an information request case TO the bank for review and approval. See information above.