Client identity verification
The provider performs document and identity checks where it offers them. The CRM shows status and result details where integrated. Your brokerage sets the requirements.
Broking Bridge CRM connects your chosen KYC provider and AML providers to your brokerage back office. The provider performs identity checks within its service scope. The CRM displays returned results beside client records, so your team can review onboarding and handle exceptions without chasing emails. Your brokerage keeps its compliance policies and final onboarding decisions.
A provider may verify identities well, but your team still needs to know what happened and what comes next. A client’s verification is pending, the provider returns a result, staff see the status or exception, and an authorised team member acts under your configured process.
Depending on the integration, the CRM can show fields such as verification status, provider reference, review flag and result timestamp. The exact fields are confirmed during scoping.
We review your provider, regions, trading platform, API availability and integration requirements.
Define supported verification levels, provider status mapping, returned fields and the action required for each result.
Clients complete digital KYC verification through the supported onboarding or provider-hosted flow.
Validate approved, rejected, pending, inconclusive, failed and unavailable-result scenarios in the test environment available for your integration.
Establish how authorised staff review statuses, manage exceptions and record decisions where supported.
API access, webhooks, sandbox availability and status synchronisation are confirmed for each provider integration and are not assumed across all providers.
The provider performs document and identity checks where it offers them. The CRM shows status and result details where integrated. Your brokerage sets the requirements.
The provider screens only if it supports AML. The CRM surfaces returned flags. Your brokerage reviews outcomes and decides.
Providers may return inconclusive results. The CRM supports approve, reject or escalate actions where available. Your brokerage defines the review process and records the outcome.
Ongoing monitoring, adverse media, liveness detection and document OCR depend on the provider and are never assumed.
Availability depends on supported integrations. Share your preferred provider and we will confirm compatibility, scope and limitations.
We will need your provider, target regions, trading platform setup and access to provider credentials.
Review each client’s status from the CRM.
Apply supported verification levels that match your policy.
Authorised staff see provider results and review status.
Exceptions get a recorded next action and an owner.
Integration scope confirmed for your regions and stack.
Best for brokerages replacing email-based verification, launching new operations, running multi-brand onboarding or centralising manual checks. Prop firm workflows are reviewed case by case.
| Area | Provider | CRM | Brokerage |
|---|---|---|---|
| Identity checks | Performs checks | Initiates or displays results | Sets requirements |
| Sanctions/PEP | If supported | Surfaces results | Reviews outcomes |
| Final decision | Supplies results | Records where supported | Retains responsibility |
| Regulatory compliance | Contracted services | Workflow tools | Own legal obligations |
Role-based access limits sensitive data where supported. Verify the provider’s retention and deletion policies, assign ownership for failed, inconclusive or unavailable results, and have compliance counsel review requirements for your jurisdiction.
Provider API requirements, custom mapping, workflow count, trading platform connectivity, and testing.
Provider verification fees and third-party licensing.
Provider compatibility, credential access, data mapping, and exception handling.
Share your provider, trading systems, and onboarding process.
A clear outline of scope, costs, and security details.
No. The provider performs checks; the CRM connects to it and displays results.
Supported providers are confirmed during your demo. Share yours and we will verify compatibility.
It depends on the provider. We confirm API access, webhooks and status synchronisation during technical scoping.
That depends on controls in your connected systems. We confirm which restrictions your setup supports.
The case follows your agreed exception process. We confirm how each case type appears in the CRM and who resolves it.
Retention depends on the provider’s policies and your contract. Review these alongside CRM access controls during implementation.
No. It supports verification workflows; your AML policies and legal obligations remain yours.
Not necessarily. Provider charges are usually separate, and we clarify them when defining scope.
That depends on the dependencies listed above. We give an estimate after reviewing your requirements.
In your demo we review provider compatibility, your current workflow and technical requirements. Bring your preferred provider, target regions, verification steps and trading platform setup.