Transaction Report Overview

What is a transaction report?

After a user has completed the verification flow, the details of their transaction will be displayed in a Transaction Report. This report is accessible from the Transactions section of your Berbix dashboard for the duration of your data retention policy. Most of the information contained in this report can also be accessed via our API. If the end user did not finish her verification, this report will be incomplete.

How do I use the Transaction Report?

The primary purpose of the Transaction Report is to help you review transactions.

Depending on your use case, you may wish to review a subset of transactions, rather than having Berbix make an automated decision in all cases. Transactions with a “Review” status can be manually actioned by a human on your team. You can configure what triggers a transaction being accepted, rejected, or sent to review through your action map.

What are the elements of a Transaction Report?

This article covers the following in detail:

  • Status and Flags
  • Additional Actions
  • ID Check Data
  • Watermarking
  • Face match
  • Session Information
  • Other transactions with identical ID
  • Access Log

Status and Flags:

On the top left side of the report, you will see the transaction status (equivalent to the “Action” field in our API response). This value will be either ACCEPTED, REJECTED, or REVIEW. If a transaction has a “REVIEW” status, it is awaiting inspection and decision by a human on your team. In the other two instances, Berbix automatically applied a decision. If this determination was made in error, a human could change the status by clicking the green “Accept” button, which would also change the associated Action API response.

The expiration date that appears under "Status" denotes when the transaction, and the underlying data, will be deleted from the Berbix system. (This time frame is determined by your data retention policy.)

The status of a given transaction is determined by the flags that appear on a verification, and your Action Map configurations.

In the example pictured above, two flags were triggered, ID sample detected--because this is a known sample ID and not a legitimate document--and ID selfie face mismatch--because the face on the document and the face in the selfie don’t appear to belong to the same person. Both of these flags are set to “Reject” in the Action Map on the example account. As a result, this transaction was automatically Rejected by Berbix.

The flags section is where Berbix surfaces what informed the decision applied to a transaction. If any of the displayed ID Flags are set to Reject in your Action Map, the transaction will be rejected. If no flags are displayed, that typically means Berbix did not detect anything out of the ordinary about the verification.

Let's look at another example:

Berbix may surface flags that do not contribute to the rejection of a transaction. For instance, in the above example, four flags were raised, but the transaction would only be rejected if one or more is set to “Reject.” Check your Action Map to see what contributes to a Reject or Review status for your users.

Hover over the flag to learn more about what it means.

Additional Actions

Under "More Actions" you'll see the options to Escalate, Block, and Delete.

Delete Transaction
Deleting a transaction permanently deletes any data for a given transaction and has the same effect as using our Delete transaction API.

Block Transaction
Blocking a transaction enables you to prevent bad actors from reentering your platform. When set, Berbix will raise a blocked flag that can be mapped to a reject action if this ID is seen in the future. (Note, Berbix will not block a bad actor based on the ID or selfie photo, only the ID details.)

Escalate Transaction
Escalating a transaction notifies the Berbix team with a provided escalation reason to review or investigate a transaction. Please escalate transactions if there is an error or bug associated with a transaction.

ID Check Data:

The ID Check section of the report contains all of the information Berbix extracted from the document, plus the photos the user uploaded. Click on the photos for closer visual inspection, or to see alternate shots provided by the user.

ID Check: Confidence and Sources

Each field in the ID Check will have an associated color (green, yellow or red), corresponding to our confidence in the source of the data:

  • Green, high confidence: Extracted from a machine readable source (2D barcode or MRZ)
  • Yellow, medium confidence: Extracted through OCR of the text on the front of the ID (and sometimes confirmed by the user) or extracted from a 1D barcode.
  • Red, low confidence: Data provided by the user only.

In the above example, all the fields have green confidence bars, indicating that the data was extracted from a machine-readable source on the document.

If we have information from more than one source, you’ll be able to see and compare all the source values.

When Berbix detects inconsistencies in the information from different sources, you will see an exclamation mark next to that field. By hovering over the confidence bar for that field, you can see the data sources on which Berbix's inconsistency detection is based.

In the below example, the information from the machine readable (2D barcode) and human readable (OCR from the front of the ID) sources match, but the user supplied different data.

In the below example, Berbix relied on the text from the front of the ID (rather than the barcode or user-input) to discern that the document is a Driver’s License.

If a 2D barcode scan is not successful, Berbix will also attempt to extract information from the 1D barcode, if possible.

In the below example, Berbix was not able to extract an expiration date (likely because of low quality images submitted by the user). The value provided for the expiration data came from the user, and has not been validated by Berbix.

ID check: Document Images

By clicking on the thumbnail images of the document, you'll see the user-provided front or back images of the ID that can be used for manual review. Note: If any of the images shown on the details page are partially cropped, clicking on the image will reveal alternative scaled shots.

Watermarking

Images exposed in the dashboard (and via the API) are watermarked in an effort by Berbix to be the best possible steward of sensitive data. Image watermarks are generated on a per-access basis and therefore can be traced to the IP address accessing the image and the timestamp at which the image was accessed.

Image can include up to two watermarks: one in the bottom-left corner and one that covers the sensitive data in the image (such as an ID or a face). The IP address and timestamp associated with the image are also rendered in a notice at the bottom of the image to discourage storing or sharing of this sensitive information.

Watermarked images are also surfaced at a lower resolution than that of the original raw image. Please contact us if the resolution or watermark prevents you from reviewing the contents of a given ID or selfie image!

Watermarks and reviews in the dashboard

When a transaction's action is review, Berbix automatically hides the larger watermarks within the dashboard in order to facilitate reviewers' efforts. In addition, for transactions that are not marked for review, or have previously been reviewed, Berbix offers the ability to selectively hide watermarks. To use that ability, click on the image you'd like to see without a watermark, and press the "Show Without Watermark" button at the bottom of the modal that gets presented to you. Please note that all uses of that functionality are logged and listed in the Logs page, and are moreover subject to a daily and monthly cap.

Face Match:

If you are using a selfie or liveness match as part of your verification flow, the resulting photos will be shown under “Face Match”. In this example, which triggered an “ID Selfie Mismatch” flag, the selfie photo has an alert because it does not appear to be a photo of the same person as the ID.

Session Information:

When available, session information can be visually compared to the address on the ID, or to subsequent sessions, as a check against suspicious activity.

Other transactions with identical Customer UID:

If a user with the same Customer UID in your system has attempted or completed multiple transactions in the period of your data retention policy, all of those attempts will be logged, and linked in this section.

If the same user goes through the Berbix flow with two different CUID’s, but the same ID document, the second and all subsequent transactions will be flagged as suspicious duplicates.

Access Log:

Berbix logs status changes on all transactions, and all watermark removals. These are stored on a per-transaction basis.