View upcoming releases, events, and major announcements.
The following items are tentatively scheduled to be released in the next two weeks:
deviceSessionId can trigger web application firewall rules, resulting in the request being blocked. To ensure compatibility, we’re changing the encoding format from JWT to Base64.deviceSessionId in an image. This change will fix an issue that impacted less than 1% of users. No action is required for customers who request the device code from our server, or who use the WebSDK as part of the Document Verification process.The following items are tentatively scheduled to be released in the next two weeks:
0000-00-00T00:00:00Z.fullName and userConsent parameters not behaving as expected in the Sandbox environment.The following items are tentatively scheduled to be released in the next two weeks:
fullName parameter will remove the restriction that requires two strings to be passed in the request body. This change will address issues with single name business entities, and will allow you to pass a single string in the API call.userId and customerUserId parameters to be returned in the error message response when included in the initial API call.The following items are tentatively scheduled to be released in the next two weeks:
deviceSessionIds that contain two consecutive dashes (--). To address this issue, we will no longer be generating deviceSessionIds that contain two consecutive dashes.locale function causing apps to crash when running on Android 7.The following items are tentatively scheduled to be released to Production in the next two weeks:
An upcoming update will improve our ability to match a first name extracted from a document to a nickname manually entered by a user. This functionality will be enabled via a new check box on the Document Verification section of the Account Settings page in Admin Dashboard.
Additionally, a new reason code will added:
This complements the existing test that matches the input first name against the document extracted first name (I822/R822), which will now be matched to known nicknames to avoid false rejects.
To help prepare for new device outputs to be delivered via our API, we'll be adding placeholders in the Device Risk API response. The placeholder elements will represent data that will be added to the API in the coming months.
To prepare for these changes, you can update your integration to accommodate parsing and storing the new data. The full scope of the planned additions and changes to the API will be documented in DevHub shortly. We'll post a link to the article in the Release Notes once it's available.
Along with the changes to the API response, we'll also begin the process of separating reason codes that are specific to risk or correlation in preparation for equivalent scores to be included. You’ll see two sets of reason codes after this change is released to production. We'll be adding a control to switch between the current and new output formats, and will enable it for each account only after we receive confirmation that your integration has been updated. There are no changes to the reason codes themselves, just their placement in the API response.
New functionality on the Admin Dashboard will enable you to filter adverse media articles by country and date range.
The following items are tentatively scheduled to be released to Production in the next two weeks:
We’re updating the default rate limits for the API from 600 transactions per minute to 10 transactions per second for each API key. If you need to increase rate limits for your account, contact Technical Support.
The following items are tentatively scheduled to be released to Production in the next two weeks.
API calls made to the ID+ endpoint that include Device Risk along with other modules will no longer fail when the Device Risk deviceSessionId is missing, but all required parameters for the other modules are included.
Note: API calls that only include the Device Risk module will continue to fail when the deviceSessionId is missing.
We’re adding a new reason code for Device Risk to cover scenarios in which the Device Risk module is called, but no deviceSessionId is provided in the request body.
We’re adding a new reason code for KYC that will be returned when a user’s name and date of birth matches that of a celebrity.
We’ll be adding the following new age related reason codes:
Note: I352 and R354 will not be available globally and must be configured for your account. Contact your Account Manager for more information.
Additionally, we’ll be deprecating the following risk code:
An upcoming update will improve our ability to match nicknames to first names.
We’ll be releasing the following enhancements for Global Watchlist:
On March 1st, we'll be releasing an update for Name to Address Correlation scores that will significantly improve Socure's ability to match names to addresses. The update includes integration of additional data sources and improvements to search and resolution techniques.
A new version of the Document Verification Android SDK (v2.0.6.28) will be released in the coming weeks. The release will include the following enhancements and bug fixes:
In the first week of February, we’re going to release 14 new reason codes. These codes provide information about IP addresses, and are applicable to multiple modules. Examples of these codes include R646: IP proxy is VPN-based and I634: Proxy is an educational institution.
Reason codes represent data points that ID+ uses to determine scores, meaning the scores returned already reflect the codes. Unless you decision based on specific codes for regulatory compliance (e.g. KYC), these codes are provided to help with manual review and provide information in part how ID+ determined a score. Reach out to your account manager with any questions.
At the end of February, the DocV team is planning to release updates to our WebSDK capture app. This includes a redesigned user interface, with additional updates to the embedded plugin for the desktop-to-mobile hand-off, a redesigned user interface, and additional instructions to aid in image processing and capture. This migration will be managed through the Socure Admin Dashboard, and will not disturb your current Android and iOS integrations. As we get closer to release, your account manager will be in touch to answer any questions.
The Electronic Consent Based Social Security Number Verification (eCBSV) module is scheduled to be released in Q2 of 2021. The eCBSV module enables you to verify if an individual’s social security number, name, and date of birth match the Social Security Administration’s records. For more information, contact your account manager.
In December, Socure put in place a code freeze, to ensure stability and consistent operation through the always high-traffic Q4.
At the end of the month, we’re going to rotate the certificate for service.socure.com. This is a semi-annual maintenance task, and it only affects customers who pin their integrations to our certificate. Those of you who do should have been contacted by a TAM to confirm the new certificate number and chain. And if you’re pretty sure but not 100% sure, reach out and double check.
Towards the end of January, we’re introducing new specificity around IP addresses. These codes will appear in the 600 range, and can apply to multiple modules:
Customers who use the React JavaScript library will soon have access to a version of the Device Risk SDK that will integrate seamlessly into mobile apps that use it on both Android and iOS. A standalone version will be available soon. Customers will also have an option to use it together with Document Verification.
Over the past few months, we’ve worked with our customers to roll out our Document Verification v2 platform, which includes new reason codes, improved algorithms, and self service configurations via Socure’s Admin Dashboard.
All of our DocV customers are now using v2, so we will begin deprecating our v1 environment. Certain reason codes will no longer be returned in production, and will be removed from the Reason Code API as of Feb 16, 2021.
Please note that all the tests associated with the soon-to-be-deprecated reason codes have been combined or translated into one of the existing/new reason codes.
I803: Document check digit integrity test passedI806: Document image is not in focusI807: Document image glare obscures the document detailsI835: Self-portrait contains one faceR803: Document check digit integrity test failedR805: Document submitted is a paper copyR806: Document image processed with editing softwareR807: Document image capture integrity failedR809: Document text has been modifiedR817: Document image has been alteredR821: Document text has been modifiedR828: Expiration date inconsistent with DOB and issue datesR829: Issue date inconsistent with DOB and expiration datesR830: DOB is not validR835: Self-portrait must contain one faceR846: Expired document is within expiration grace periodR847: Document is going to expire out of the set grace periodV806: Document image resolution is insufficientV818: Document image is not in focusV819: Document image glare obscures the document detailsV827: Document is within six months of expirationV836: Self-portrait was not considered in decisionIt’s not technically in December, but this is important, so we’re announcing it now. In January 2021, we’re going to rotate the certificate for service.socure.com. The good news is, this is a semi-annual maintenance task. The other good news is, it isn’t applicable to all customers—only those who pin integrations to our certificate. For those of you who do, you’ll need to add our new public certificate to your keystore, then validate it with a new fingerprint. However, it’s important to confirm whether this is applicable to your integration, so if you aren’t sure, start asking now.
Now, on to the the features scheduled for the upcoming release in December:
On the heels of last month’s iOS update, we’re planning to release an update to the Android SDK this month. Both are available in our GitHub repository. And if you have questions, or need access to our GitHub repositories, please reach out to your account manager.
The new capture interface we wrote about last month will be released in December. We’re excited to announce a new slate of features, including an improved capture experience for our DocV webSDK.
Support for native iOS and Android applications is coming to the Device Risk product by mid-December. At that point we will provide SDKs that can be used to collect device metadata from mobile apps and support risk lookups, expanding our coverage beyond the browser. We are introducing reason codes to indicate whether the device being used to access your service is real or virtual (I423: “Device is a physical device” and R403: “Device is a virtual device”).
The Feedback Endpoint is scheduled for release on November 15. This endpoint provides an alternate method for customers to send feedback data, following the same authentication and security protocols as the ID+ API. Uses industry standard models published by the Federal Reserve Fraud Classification labels.
We’re adding a new node under the Decision Module that shows additional information. When users call the Decision module, the Details node will contain information such as codes and scores that influenced the decision. Reach out to your account manager to enable this feature.
We’re adding a new code (I930) to KYC for notable names. People in the public eye, such as celebrities, politicians, and high-profile individuals, are at a higher risk of identity fraud because of the public availability of PII. KYC will check identities against a list of notable personalities and alert you to any matches.
Watchlist will support passing userId and customerUserId in the request. These parameters will be returned in subsequent Watchlist Monitoring webhooks and snapshot endpoints. This gives customers another method to manage traceability among transactions, besides using the referenceId.
We’re constantly improving both our reg-tech capabilities, and the features that make our solutions the best in the industry. This month, we’re releasing additional DOB filters for the KYC and Watchlist modules. In addition to the new filters released last month, the additional filters include:
These configuration options will be available on the Settings page of the Admin Dashboard.
We’re doing a significant amount of work on our image capture workflow. While these are primarily code and backend changes—you won’t see new features or options—you should see small, steady improvements in speed, capture accuracy, and overall experience this month. We's also released a minor improvement to the DocV Event manager, in which we notify customers when the capture app session is expired. This information is returned in the Event Manager Webhook response.
Finally, we’re working on a new and more intuitive WebSDK Capture interface. It won’t be ready this month, but it’s on our roadmap for December. We’re pretty excited, and can’t wait to share the improvements. Look for more information in the coming weeks.
We’re going to expand support for Device Risk in Sandbox. Customers will be able to utilize our Sandbox to send Device Risk requests and receive responses with reason codes I401 (“Device token previously encountered”) and I414 (“Session connected using a proxy”). See the Sandbox User Guide for instructions on how to trigger these scenarios.
As we refine our Device Risk module, we’re adding new reason codes that provide additional user insight. These codes will specify the device category, type, and model.
Both Global Watchlist and KYC customers will receive new DOB fuzziness tolerance match settings. When matching DOB, customers select one of four options (e.g. “Exact YYYY”). The new release will bring the total number of match options to nine, adding additional choices such as 1 Year Radius, 2 Digit Transposition YYYY/MM, 2 Digit Transposition YYYY. The release will not change your existing defaults.
KYC will have the ability (with particular contractual requirements in place) to verify active duty military and dependents. Submit a KYC request, and the module will return the reason code R975: MLA covered borrower status to indicate status. Contact your Account Manager to learn how to take advantage of this new service.
KYC will return a new reason code if the SSN/ITIN provided contains only four digits. Reason code I905: SSN/ITIN provided at input contained only 4 digits provides extra awareness, in case you do not have front end validation for nine digits, but expect a match on the full nine.
In Global Watchlist, we're adding a new response parameter that explains how names you submit match the names on the watchlist. The matchType field in your Watchlist response will explain how the names match (e.g. nameExact, akaPhonetic). Look for the new fields in the comments object of the response.
Two new Global Watchlist reason codes will show if the address is in a High-Intensity Drug Trafficking Area (HIDTA) or an or High Intensity Financial Crime Area (HIFCA) county:
R187: Address resolves to a High-Intensity Drug Trafficking AreaR188: Address resolves to a High-Intensity Financial Crime AreaSocure’s Event Manager monitors names and proactively pushes out Add, Change, and Delete events for the Global Watchlist. Sandbox will now support Event Manager, enabling users to receive notifications from the test environment.
Lots of changes in Document Verification (we call it DocV). Also, make sure you check out the recently released section for more DocV updates.
DocV can now shift strategies on the fly, from lenient to strict, based on decision logic and risk threshold. Specific thresholds can trigger this strategy shift; see the WebSDK guides for configuration options.
DocV will return a new reason code when the user does not submit an image of the back of the license. The new code is I854: The back of the license was not passed; no barcode to extract information.
Document Verification is often a step-up authentication option, such as when KYC fails or the Fraud Score is high. Now, customers who use Document Verification can link the two transactions by passing the original referenceID as a parameter in the step-up transaction. This creates better traceability.
Document Verification customers who use the WebSDK, and are part of Socure’s early access Device Risk Intelligence program, will receive additional Device Risk parameters in their API responses. If you are not part of the Device Risk Program but still use the WebSDK, the API behavior will not change. For more information, or to learn about our Device Risk Intelligence program, reach out to your account representative.
Device Risk is introducing two new parameters this month, one input and one in the response:
Users will export transaction history into a CSV file. We’re also offering configuration options for the exports. Contact Socure to enable this feature.
Users will select email as a notification method for Watchlist Notifications, instead of receiving the notifications via webhooks. Configure this option on the Event Manager Tab in the Admin Dashboard.