Skip to content
DELCOS Financial Infrastructure

Financial Infrastructure for Payment and Compliance Operations

Every transaction runs through two operating systems that were built separately. One moves the money. The other decides whether it should move, and has to evidence that decision long after it has moved. DELCOS documents both: which participant holds authority at each step, which record governs when two systems disagree, where a control sits and who answers for it, and how a failure propagates once it starts.

DELCOS publishes in two layers. Permanent pages own the stable subjects — a system, a mechanism, a control, a boundary of responsibility — and each is kept current against the sources behind it. Insights takes something specific and recent, a named failure or a regulatory change, and works back to the systems that produced it. Both describe how the infrastructure operates; neither gives advice on a financial decision.

Explore PaymentsExplore Compliance

Payments

Execution, messaging, settlement, ledgers, and reconciliation.

Compliance

Identity, screening, monitoring, investigations, and controls.

Transaction lifecycle

The operating layer where payment and compliance systems meet.

Insights

Cases, architecture, regulation, and practitioner analysis.

Sources and evidence

Primary records establish rules, states, responsibilities, and outcomes.

Two Permanent Domains

Payments and Compliance divide the stable material between them. Each hub maps its domain and routes to the system pages beneath it. The depth lives there.

Payments

How an instruction acquires authority, reaches a counterparty institution, settles, and leaves a record that survives challenge. The systems below divide that work, and each holds one part of it.

Payment SystemsParticipants, rails, access models, and the relationship between clearing and settlement. Settlement SystemsSettlement models, assets, timing, and the liquidity each arrangement demands. Payment MessagingHow an instruction is constructed, routed, and kept in status continuity across systems that do not share one. Ledger ArchitecturePosting models, balance representation, and which record answers when systems disagree. Payment ReconciliationBreak identification, categorization, and who owns a resolution once a difference is found. Payment OperationsCut-offs, funding, exception handling, and the execution responsibility that sits behind a published schedule. Banking-as-a-ServiceSponsor-bank operating models, and what a program operator holds versus what the bank retains. Agentic PaymentsDelegated authority and its limits, agent credentialing, and the point at which a mandate becomes an instruction.

Compliance

Compliance runs on what an institution can demonstrate afterward. Which participants it identified, what it monitors, how a signal became a decision — each has to remain provable to an examiner years later. The systems below carry that chain.

Compliance ArchitectureHow policy, risk assessment, controls, and governance assemble into an operating program. KYC & KYBCustomer and business identification, beneficial ownership, and due diligence that continues after onboarding. AML ProgramsProgram structure, enterprise risk assessment, and the obligations a program has to discharge. Transaction MonitoringData inputs, scenario design, alert generation, and triage into investigation. Sanctions ScreeningName and payment screening, match review, and the release decision at the end of it. Regulatory OperationsReporting, examination support, remediation, and the evidentiary continuity all three depend on.

One Transaction, Two Domains

The same transaction passes through both domains, at the same moments. A payment often fails because one of them assumed the other had done something.

Instruction

A payment enters carrying an amount, a beneficiary, and an assertion about who authorized it. Validation and routing sit with the payment layer. At the same moment, the compliance layer is deciding whether this participant is one the institution has identified and whether the transaction is one it has agreed to carry. Both layers read the same message and ask different questions of it.

Screening and release

Before the instruction leaves, it is screened against sanctions and internal controls. A hit stops the payment. What happens next is a compliance decision — review, escalate, release, or refuse — but the cost of it accrues in payment operations, because a held payment misses a cut-off and a missed cut-off changes when value arrives.

Execution and settlement

Clearing and settlement proceed on their own logic and their own timetable. At this stage the compliance layer observes: monitoring scores what happened against expected behavior. Irrevocability arrives at a point the settlement arrangement defines, not at the point review finishes.

Record and evidence

The payment layer posts and reconciles. The compliance layer retains what it decided and why. These are two records of one event, built by different teams for different reasons, and whether they can be linked afterward determines whether a dispute or an examination can be answered at all.

These crossings belong to the pages below.

Payment LifecycleThe states an instruction passes through, and the hand-offs between them. Payment ControlsThe control objectives applied to an instruction, who executes them, and what evidence each produces. Settlement FinalityThe point at which a transfer becomes irrevocable, what establishes it, and what follows for anyone relying on it. Settlement LiquidityThe funding a settlement arrangement demands, and when it has to be there. Cross-Border PaymentsCorrespondent chains, and how each additional institution adds a screening point and a funding requirement. Case ManagementHow an alert becomes an investigation, and what the file has to contain when it closes. Bank-Fintech ResponsibilityHow control duties are allocated between an institution and its operating partners, and where the allocation leaves gaps.

Insights

Analysis of what is happening now, traced back to the systems that explain it. An article starts from something specific — a named failure, an enforcement action, a regulatory change, a pattern visible across several institutions — and works down to the permanent pages that own the mechanics. It reconstructs an event; it does not become the definition of the system underneath it.

View all Insights

How This Is Published

DELCOS is independent. It sells nothing, recommends no vendor, and has no commercial relationship with the institutions it writes about. What that independence is worth depends on what stands behind a claim.

Primary records come first here — regulation, scheme rules, court filings, official operational records, technical standards. Secondary reporting is used where primary records do not reach, and it is identified as such. The order matters. Each page carries the register of what it relied on, so a statement can be traced to the document behind it rather than to the platform asserting it. Permanent pages record when their sources were last reviewed, because material that was accurate in one rule environment does not stay accurate by default.

Each part of that work has a named person behind it, in a role that states exactly what they are answerable for.

Editorial methodology, sources, and responsibility