BlockPay
Govern the transaction.
For payment teams running compliance into the transaction lifecycle, not after it.
Payment compliance, applied after the fact.
Payment compliance is largely a post-execution discipline. A payment is initiated, submitted, screened against sanctions and AML rules, queued for review, and then either settled or pulled back. Each pulled-back payment costs the institution operational time, regulatory exposure and customer trust. Each settled payment that should have been flagged costs more.
Three structural problems compound. Reactive compliance — controls applied after the transaction has already begun. Disconnected orchestration — compliance, sanctions screening, fraud monitoring and payment routing operating as separate systems without a coordinated state. Liquidity friction — funds in transit while controls play catch-up.
Institutions running multi-rail, multi-jurisdiction payment operations feel this most acutely — each rail with its own controls, each jurisdiction with its own thresholds, and the cost of getting a payment wrong a multiple of its value. Reactive compliance is a structural cost of fragmented payment infrastructure, not a tooling problem.
The payment control layer of the Block Infrastructure architecture.
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.
BlockPay is the payment control layer of the Block Infrastructure architecture — the point of governance applied before execution. It depends on BlockID for verified counterparty context, references BlockTravel where digital asset transfer obligations apply, and feeds compliance state into BlockSettle for settlement-conditional flows. Compliance moves to the front of the transaction. Execution becomes a downstream effect of having already satisfied the conditions.
Compliance at the front of the transaction.
Pre-execution screening
Sanctions, AML and fraud rules applied at the moment of payment intent, not after submission. The transaction either satisfies controls or it doesn’t begin.
Multi-rail orchestration
Fiat rails — SEPA, SWIFT, Faster Payments, ACH, wire — under one coordinated compliance state. Same posture across every rail you operate.
Policy-driven routing
Payments routed by compliance posture and operational rules, not by availability or cost alone. Routing decisions are auditable, explainable, and codified — not discretionary.
Real-time decisioning
Block, allow or hold decisions made on current screening state. No next-day batch reconciliation, no overnight queue. The decision attaches to the payment, not to the operations team.
API-first architecture
REST and event-driven APIs. Drop into existing payment platforms, treasury systems or compliance pipelines without re-architecture.
What BlockPay is built on.
- DABA
- MiCA
- FATF Travel Rule
- GDPR
- FCA
- MAS
- OpenAPI 3.0
- Zero-knowledge Proof
- mTLS
- Immutable audit logging
- OAuth2
The standards above are not aspiration — they define how BlockPay is built and how it must operate. ISO 20022 is the canonical message standard for modern payment orchestration; we adopt it as the floor.
Five lifecycle states, one event stream.
BlockPay exposes a REST API and an event subscription layer for the payment lifecycle: intent, screening, decision, execution and settlement. Webhook events fire on each state transition and on screening exceptions.
The sandbox environment supports synthetic transactions across every rail BlockPay supports. Decisioning behaviour is deterministic in sandbox — the same scenario always produces the same outcome.
Where BlockPay does the load-bearing work.
Fraud Prevention
Pre-execution participant verification, transaction governance and movement compliance — coordinated.
TCSP / Introduced Business
Verified participant attestation shared between TCSPs and onboarding institutions. Introduced-business onboarding without re-verification at the payment layer.
BlockPay does not work alone.
BlockID
Reusable identity verification. BlockPay references BlockID for verified counterparty context on every transaction.
BlockTravel
Travel Rule, sanctions screening and policy enforcement for digital asset transfers. BlockPay’s counterpart for digital asset movement.
BlockSettle
Atomic and conditional settlement. BlockPay’s compliance state feeds into BlockSettle for settlement-conditional flows.
Move payment compliance to the front of the transaction.
Design partners get early access to BlockPay, a direct line to the build team, influence on the V1 roadmap, and preferential commercial terms when BlockPay moves out of design partner stage. We ask for genuine integration intent, a structured feedback loop with named technical and compliance counterparts, and a mutual non-disclosure agreement.