Skip to main content

Goldsky

Tokenized loan participation payments

Talk to our team

What are tokenized loan participation payments?

Tokenized loan participation payments are the interest and principal a lead bank passes on to the banks that bought shares of a loan, known as loan participations, paid in tokenized deposits instead of by wire.

Banks that sell or buy participations need every participant’s share of each borrower payment paid and recorded against the right loan, because the participation agreement and each bank’s loan records depend on it.

Goldsky writes each payment from the chain to your database, decoded and corrected after reorgs, while your deposit token platform makes the payments and your loan systems match them to loan shares.

You can build it two ways: stream each participation payment into your own database with Turbo Pipelines, or index payments in a subgraph that sends a webhook for each one.

Who makes tokenized loan participation payments?

Community and regional banks that sell or buy loan participations, and crypto-native banks that settle them in tokenized deposits.

How a tokenized loan participation payment is paid and matched

The diagram follows one borrower payment, from the lead bank receiving it to the payment cycle closed by loan operations, and shows who does each step. Your setup may differ.

Your business, step 1: Receive the borrower’s paymentInterest or principal reaches the lead bank
Your business, step 2: Deposit token platformPay each participantDeposit tokens sent per loan share
Goldsky, steps 3–4: TurboLand each paymentDecoded rows beside your loan records
Your business, step 5: Match to the participationBy wallet, amount and date, in your database
Your business, step 6: Close the payment cycleLoan ops sees every participant paid
  • Goldsky
  • Your provider

Ways to track tokenized loan participation payments

Payments from the pipeline become rows beside your loan records, corrected in place after a reorg; the subgraph serves payments over GraphQL and pushes each change to an endpoint you run, which applies it.

Usual setupOption 1: Stream to your database
Best for
Payments as rows beside your loan records
Products
Turbo
What you run
The destination: your database, queue or bucket, or a Postgres database Goldsky hosts
What you write
Pipeline YAML and SQL; TypeScript transforms when needed
Where your data lives
In your own database or systems
How results reach you
Pushed to you
Option 2: Subgraph with webhooks
Best for
A hosted payment API, with a push per payment
Products
Subgraphs
What you run
Nothing; Goldsky runs indexing, storage and the API
What you write
A schema and mapping handlers, or a no-code or low-code config for simple contracts
Where your data lives
Hosted by Goldsky
How results reach you
You query; changes are pushed

Option 1: Track tokenized loan participation payments by streaming to your database

Goldsky runs a pipeline that decodes every deposit token payment from the lead bank’s wallets and writes it to a table in your database, beside your loan records, where your rules match it to a participation.

When to stream participation payments to your database

Your loan system or its reporting already reads from a database you run, and you want payments there as rows you can join to loans and participants.

What you’ll need

  • Goldsky Turbo
  • A deposit token platform that pays each participant
  • The lead bank’s paying wallets and each participant’s receiving wallet
  • Your loan servicing records of loans, participants and shares
  • A database you run, next to your loan system

  1. Receive the borrower’s payment

    A participation payment starts when the borrower pays the lead bank, which then owes each participant its share.

    Loan servicing records the payment, splits it into interest, principal and fees by the loan’s terms, and works out each participant’s share from its percentage. A share worked out on the wrong balance carries into every payment after it.

  2. Pay each participant

    Each participant bank receives its share as tokenized deposits, which move between banks on a chain.

    Your deposit token platform sends one payment per participant from the lead bank’s wallet. A standard token transfer records only the sender, the recipient and the amount, with no loan reference, so matching relies on wallet, amount and date unless your deposit token adds a memo field.

  3. Land each payment in your database

    Handled by Goldsky Turbo

    Loan operations needs every payment that left the lead bank’s wallets as a record it can check, without anyone reading a block explorer.

    Each transfer from a paying wallet has to be decoded into sender, recipient, amount, transaction and any reference field, and written once. A payment missed here looks like an unpaid participant.

    With Goldsky, a Turbo Pipelines pipeline can decode the deposit token’s events, keep transfers from the lead bank’s wallets and write each one to a table keyed on its id.

    Upsert rows into Postgres (opens in a new tab)

  4. Correct payments undone by a reorg

    Handled by Goldsky Turbo

    Sometimes the chain replaces its newest blocks (a reorg), and a payment you recorded can disappear or move.

    Your payment table has to follow the chain when that happens. If it doesn’t, loan operations books a payment the participant never received.

    Turbo Pipelines passes reorg corrections through as updates and deletes, and a database sink with a primary_key applies them to the same rows.

    How reorgs reach your database (opens in a new tab)

  5. Match each payment to the participation

    A payment only counts once you know which loan and which participant’s share it settles.

    Join each payment to your participation records on the loan reference, or on wallet, amount and date if there is none, and flag anything that doesn’t match. Two payments of the same amount to one participant on one day are both real, so the match can’t rely on amount alone.

  6. Close the payment cycle

    Loan operations has to confirm every participant was paid what it was owed for this borrower payment.

    Check that the payments add up to the amount due to participants and that each one is matched. An unmatched or short payment goes back to the lead bank to fix before the next borrower payment arrives.

What to know about streaming participation payments

  • Goldsky runs the pipeline; you own the database and the matching rules.
  • The pipeline’s SQL sets the columns, including any loan reference the payment carries.
  • Rows keyed on the payment’s ID are corrected in place after a reorg, and a repeated delivery overwrites the same row.

Option 2: Track tokenized loan participation payments with a subgraph and webhooks

A subgraph turns the deposit token’s transfers from the lead bank’s wallets into payment records, serves them over GraphQL and sends a webhook to your backend for each new one.

When to index participation payments in a subgraph

The deposit token lives on one EVM chain and you’d rather query payments from a hosted API, with a push to your loan system, than keep them in a database you run.

What you’ll need

  • Goldsky Subgraphs
  • A deposit token platform that pays each participant
  • The lead bank’s paying wallets and each participant’s receiving wallet
  • Your loan servicing records of loans, participants and shares
  • An HTTPS endpoint on your backend for the webhooks

  1. Receive the borrower’s payment

    A participation payment starts when the borrower pays the lead bank, which then owes each participant its share.

    Loan servicing records the payment, splits it into interest, principal and fees by the loan’s terms, and works out each participant’s share from its percentage. A share worked out on the wrong balance carries into every payment after it.

  2. Pay each participant

    Each participant bank receives its share as tokenized deposits, which move between banks on a chain.

    Your deposit token platform sends one payment per participant from the lead bank’s wallet. A standard token transfer records only the sender, the recipient and the amount, with no loan reference, so matching relies on wallet, amount and date unless your deposit token adds a memo field.

  3. Index each payment

    Handled by Goldsky Subgraphs

    Loan operations needs every payment from the lead bank’s wallets as a record it can look up by loan, participant or date.

    Each transfer from a paying wallet has to become one payment record with its amount, recipient, transaction and any reference field. A record your mappings skip never reaches loan operations.

    Subgraphs runs your mappings over the deposit token’s events and serves the payment records at a GraphQL endpoint, which can require an API token.

    Set up public and private endpoints (opens in a new tab)

  4. Push each payment to your loan system

    Handled by Goldsky Subgraphs

    Your loan system should hear about a payment when it lands, without polling the API.

    Each new payment, and each correction after a reorg, has to reach your endpoint with enough detail to tell one from the other. Changes can arrive out of order, so your endpoint can’t rely on arrival order.

    With Goldsky, a webhook on the payment entity sends an INSERT for each new payment, and the block_range on each version tells a reorg rollback apart from an ordinary update.

    Set up subgraph webhooks (opens in a new tab)

  5. Match each payment to the participation

    A payment only counts once you know which loan and which participant’s share it settles.

    Join each payment to your participation records on the loan reference, or on wallet, amount and date if there is none, and flag anything that doesn’t match. Two payments of the same amount to one participant on one day are both real, so the match can’t rely on amount alone.

  6. Close the payment cycle

    Loan operations has to confirm every participant was paid what it was owed for this borrower payment.

    Check that the payments add up to the amount due to participants and that each one is matched. An unmatched or short payment goes back to the lead bank to fix before the next borrower payment arrives.

What to know about indexing participation payments in a subgraph

  • Goldsky hosts the subgraph and its GraphQL endpoint; you write the schema and mappings.
  • Webhooks for one change can arrive in any order, so your endpoint keeps its own last-updated time per payment.
  • A reorg arrives as a change to a record’s block range, and your endpoint applies it.
  • A subgraph indexes one chain, so payments on several chains need one subgraph each.

What you control

Your team
  • Receive the borrower’s payment
  • Match each payment to the participation
  • Close the payment cycle
Your providers
  • Deposit token platform

Questions and answers

What is a loan participation?

A loan participation is a share of a loan that the lead bank, which made the loan and keeps servicing it, sells to other banks. The borrower keeps dealing only with the lead bank, which collects each payment and passes on every participant’s share by its percentage. Banks use participations to stay within lending limits or spread risk. When the payments move in tokenized deposits, each one is a transfer on a chain that the lead bank and participants can match to the loan.

Security and deployment

  • SOC 2 Type IIIndependently audited security controls.
  • Dedicated infrastructureSingle-tenant options for production workloads.
  • Data residencyCloud, on-premises or co-located.

More use cases that run corporate actions

Use cases built the same way

Track tokenized loan participation payments with Goldsky

We’ll map it to your systems and show you what Goldsky runs, so your team builds the product, not the pipelines underneath it.

Talk to our team

© Endless Sky Inc. All rights reserved.

PrivacyTermsSecurity

System status