TCSP / Introduced Business
Verified participant attestation shared between TCSPs and onboarding institutions. Introduced-business onboarding without re-verification at the payment layer.
For TCSPs and the institutions that accept their introductions, where re-verification is operational friction with no compliance benefit.
The same KYC, performed twice.
Introduced business is a structurally sound model in regulated finance. A TCSP onboards a customer, performs KYC and KYB to a regulatory standard, and refers the customer to a counterparty institution — a bank, a PSP, an EMI. The receiving institution typically performs the same KYC over again. The work is duplicated, the regulatory benefit is none.
Two structural problems compound. Reverification cost — the receiving institution carries the operational burden of work that has already been done elsewhere. Customer friction — the customer is asked to provide the same information twice, in different formats, with different evidence requirements. Both compound when the introducing TCSP serves multiple counterparties.
TCSPs and the institutions that accept their introductions feel this most acutely. A high-quality TCSP’s verification work has provable value the receiving institution cannot capture without giving up its own controls. Reverification is a structural cost of fragmented identity infrastructure, not an introducing-agreement problem.
One verification. One audit trail. Two parties served.
Verified participant attestation
The TCSP issues an attestation through BlockID at the time of onboarding. The attestation is auditable, cross-jurisdictional and referenceable across the network.
Receiving-institution acceptance
The receiving institution can rely on the TCSP’s attestation without re-verification. Selective attribute proofs let the institution satisfy its own evidence requirements without retrieving the underlying records.
Pre-execution payment compliance
Payments under the introduced relationship inherit the same pre-execution compliance posture as direct relationships. Sanctions, AML and policy controls apply at intent, not after.
Coordinated audit trail
Identity provenance, attestation chain and payment compliance state are recorded as a single coordinated audit artefact. The TCSP and the receiving institution each have the record they need; the customer does not have to provide it twice.
Identity passes through. Payment compliance carries through.
01 — Identity Trust
BlockID
Verify the participant.
02 — Payment Control
BlockPay
Govern the transaction.
03 — Digital Asset Transfer Compliance
BlockTravel
Enable compliant movement.
04 — Settlement Certainty
BlockSettle
Settle with confidence.
TCSP / Introduced Business activates BlockID’s identity trust layer and BlockPay’s payment control layer. The TCSP’s verification work, captured as a BlockID attestation, is referenced by the receiving institution. Payments under the introduced relationship carry the same pre-execution compliance posture as native relationships. The introduction passes through and the work does not need to be done again.
Inherited from BlockID and BlockPay.
- FCA
- MiCA
- FATF
- PSD2
- GDPR
- MAS
- ISO 20022
- OpenAPI 3.0
- OAuth2
- mTLS
TCSP / Introduced Business inherits the regulatory and technical standards of BlockID and BlockPay. The use case is governed by the relationship between the introducing party’s regulatory regime and the receiving party’s — both must be satisfied. The architecture supports the strictest applicable framework on either side.
Onboard once. Accepted everywhere.
Design partners working as TCSPs, or as the institutions that accept their introductions, get early access to the coordinated capability, a direct line to the build team, and influence over how attestations and payment compliance state are exchanged. We ask for genuine integration intent, a structured feedback loop with named compliance and operations counterparts, and a mutual non-disclosure agreement.