Credentials are licenses, permits, or certifications that give a third party the authority to perform a service or activity in a particular location. For example, an entity could require a driver's license to drive a truck in the state of Georgia, a food handler card to run a catering business in San Diego, or a mountaineering permit to lead a mountain climbing hike in Hungary.
What makes credentials different is they're focused around where the activity is being done. Entities are required to provide evidence from an issuing authority – an agency with the regional or municipal authority to issue the necessary documents for the given activity.
Pre-requisites for using credentials in the TPRM platform
It’s highly recommended that you have at least one Credential Type custom property when using credentials. This allows you to define the specific credentials each entity is required to provide and enables the use of these properties in assignment rules, both of which will help reduce the overall number of risk profiles you’ll need.
There are no other configurations or special settings required to use credentials.
Configuring credentials in TPRM risk profiles
Credentials are treated every other kind of requirement in the TPRM platform. They can be combined in risk profiles with any other risk requirements that need to be evidenced by an entity. For example, you can have someone who needs auto insurance and a driver's license, where the auto insurance is the insurance piece and the driver's license is the credential piece.
There are currently 22 distinct risk requirements for credentials in the TPRM platform. Each credential-based risk requirement is based around a theme, such as Cosmetologist, Flying License, or Plumber License. Within each theme, you have the ability to drill down to the individual credential you care about.
Credential-based risk requirements can be used in evaluation rules.
Every credential-based risk requirement has the following criteria:
-
Credential Type: This is the most important criterion for any credential-based risk requirement – the specific type of credential you care about.
- Each requirement has tens or hundreds of distinct credential types that can get very specific, such as a barber license from Alabama that's issued by the Alabama Board of Cosmetology and Barbering.
- You can choose a specific credential type for any entities assigned to a risk profile (explicit configuration) or set this criterion to a custom property so that each entity can be enrolled to provide a unique set of credentials (implicit configuration).
- For the greatest flexibility and least amount of risk profiles, we recommend using a custom property for Credential Type.
Explicit configuration: all assigned entities will need the same credential
Implicit configuration: assigned entities each require their own credential(s)
- Credential Valid: Whether the credential is active and in good standing.
- Credential Stipulations: Whether there are any restrictions on the use of the credential.
- Entity Name: Whether the entity’s name matches what’s extracted from the credential. Mismatched names will create actions for the you to review (the same as entity names on a certificate of insurance).
-
Expiration Date: Whether the credential has expired.
- There are some credentials that don't have expiration dates. In those cases, if we don't collect an expiration date because there just isn't one, we just assume it never expires and the entity is compliant for this criterion.
- We don't burden you with having to know whether a given credential has an expiration date or not, because it could vary depending on the type of credential and the issuing authority.
- Presence: This criterion checks whether or not the entity provided a credential in their submission. We'll mark the presence of a credential as “no” if it doesn’t fit into the overall risk requirement – for example, if a driver’s license was provided when a flying license was expected.
-
Validated by Issuing Authority: This is an optional criterion where we'll go the extra mile to call an issuing authority – if they are available or responsive – and validate whether the provided credential is authentic.
- This is a billable action, so contact your customer success manager for more details.
Using credential types for risk profile assignments
You can also use custom properties for credential types in risk profile assignments. This is a more dynamic configuration than other assignment rules, as it’s based on the credential types each entity is required to provide. When using this kind of assignment rule, we recommend using the implicit configuration shown in the previous section for maximum benefit.
When you create an assignment rule, you can choose a Credential Type custom property. You’ll then select a risk requirement. This is how the rule will work: any entities with at least one credential type entered in that custom property that is part of the selected risk requirement will be automatically assigned to the risk profile.
For example, let’s say you have a custom property called “Required Credentials.” You create a risk profile for Drivers License and set the Credential Type criterion to use that property. You then set the assignment rule to use the property and choose the Drivers License risk requirement. Any entity that you enroll that requires at least one credential type from the Drivers License risk requirement will be assigned to that risk profile.
In this screenshot, “Required Credentials” is a custom property
This setup is extremely useful and efficient if you have entities that can have a broad range of credentials, as they’ll be asked to provide only what they need. It also reduces the overall number of risk profiles you need to build, as you’ll only need a single risk profile per distinct risk requirement. Finally, setting up profiles per known risk requirement also prevents you from having to know which credential falls under which risk requirement (is catering Food Services or Hospitality?) – simply set up a risk profile for each one and let the assignments happen as needed.
You can leverage these assignments to include any other needs for your assigned entities. For example, you could set up a risk profile so that any entity with a drivers license credential also needs to provide auto insurance. The credential type assignment rule is what’s used to make the assignment – you wouldn’t need a second custom property to also include auto insurance.
Use of credential types in assignment rules is optional – you are free to use other types of rules and custom properties depending on your needs.
Completing a credential verification in the Evident Network
Whenever an entity is asked to provide a credential, they’ll see a dedicated input in the Evident Network that shows the requested credential’s name and issuing authority. The entity can provide one or more documents for each credential. If more than one credential is required, each will be requested on its own screen, one at a time.
As with other risk requirements, entities can choose to decline a credential. When they do, they’ll see the same list of four reasons to choose from: decline the submission, request an exception, not renewing, don’t have the requested document(s).
When credentials are included in the same verification with other risk requirements, they’ll appear after document verifications (such as W-9 forms) and before complex inputs (such as insurance).
Viewing extracted data and information in the TPRM platform
Each credential is treated as if were a distinct risk requirement – each has its own compliance status and extracted data. The key difference is the level of detail you see: for example, the risk requirement displayed is not simply a driver's license – it’s a Class D driver's license from the Louisiana Office of Motor Vehicles.
Within each credential, you'll see all of the extracted information, identify any non-compliant reasons, and grant exceptions. The non-compliant messaging is clear to both you and your entities where they've fallen short, as the information is specific to the relevant credential.
The Submission History modal is also descriptive for each credential evidenced by an entity. You’ll see the submission dates, associated documents, indicators for when an entity did not respond, and any decline reasons.
Unlike insurance-based risk requirements, the documents shown with each credentials are only those that were uploaded on that screen in the Evident Network. This offers you a more targeted view of what an entity provided for a given credential.