How to begin

For someone who has not got a workspace yet. Read it once end to end before you start.

The shape of it

Step 2 runs in parallel with everything else and is the one that decides whether any of the rest is worth doing. Start it on day one.

1. Apply for a workspace

Go to spcr.io, sign in or create an account, and complete the workspace request. You will be asked for:

• Your company, jurisdiction, registration number and regulatory status.
• Whether you originate receivables or fund them. This decides which workspace you get.
• How custody should be handled. You hold the receivables with a custodian you already use, or STOKR arranges it.
• If STOKR arranges custody, a backup address: somewhere you control, where your certificates would be sent if they ever had to be released out of STOKR custody. You can leave it blank and set it later, but see step 4.

2. The documentation work, which starts now

The step most often skipped, and the one with the longest lead time. Read it before you register anything.

What the problem is

SPCR records that a certificate exists and which address holds it. The certificate is a representation of the receivable. It is not the receivable, and moving it is not an assignment.

Legal title to a receivable passes under your assignment or purchase documentation, governed by whatever law applies to it. So there are two transfers, and they have to stay aligned:

1. the legal assignment of the claim, and
2. the on-chain transfer of the certificate.

If they come apart, the registry stops meaning anything:

• Certificate with A, claim assigned to B. B owns the receivable but the registry shows A holding it. A third funder checking the registry gets a truthful answer to the wrong question, and B can prove nothing with it.
• Claim assigned twice, certificate moved once. The registry reports one sale and cannot see the other. The double-pledge guard has been routed around without ever being triggered.

Neither is a flaw in the registry. Both are what happens when a contractual transfer and a technical one are allowed to happen independently.

What your documentation has to achieve

Put to your counsel, the documentation needs to:

• Define the certificate and identify it. The registry contract, the chain, and the specific certificate, by its identifier or by the Loan ID and pool the identifier is derived from.
• Tie transfer to transfer. Any assignment, sale, sub-participation or pledge of a receivable must be conditional on, and simultaneous with, transfer of the corresponding certificate. And the reverse: no transfer of a certificate other than as part of a transfer of the claim it represents.
• Oblige the originator to register, before the receivable is offered to any funder, and never to register the same receivable twice.
• Say what happens if they do diverge. Which record governs, and a covenant to remedy within a stated period. Somebody will get this wrong once; the documentation should already know what to do about it.
• Deal with the pool passkey. It is the credential that lets a holder verify receivables in that pool, so cover who may hold it, confidentiality, and what happens on a leak or on a sale of the pool.
• Cover release from custody, if STOKR holds custody for you. See If SPCR disappeared, which sets out the obligation that should survive termination and bind a liquidator.

Where this language belongs depends on your structure: usually the receivables purchase or facility agreement for the covenants, and the assignment or transfer certificate for the mechanics.

3. Your workspace opens

You get an email with a link, and your workspace lives at its own subdomain, for example yourco.spcr.io. Sign in with the address you applied with.

Who else can get in depends on how it was set up: normally everyone on your email domain, so colleagues need no invitation. It can instead be restricted to named addresses, which is right for one person at a large organisation. Ask STOKR which yours is if it matters.

4. Set and prove a backup address

Only if STOKR holds custody for you. Skip this if you brought your own.

Open Confirm my address, produce a confirmation, and use Set as my backup address on the result. That signs a challenge with the address's own key, which is what turns it from an address somebody typed into one you have demonstrably got access to. STOKR whitelists it in custody only once it is proven.

Do it now rather than when it matters. It cannot be arranged during the incident that needs it, and an unproven address is not a destination anyone will release to.

5. Decide your Loan ID scheme

Permanent. A Loan ID is taken forever once registered, registry-wide, and can never be reused or re-registered, which is what prevents double-pledging.

The rules are in Loan ID rules: no spaces, 5 to 64 characters, letters, digits and - _ / . only.

Three things to settle before you generate any:

1. Use your own existing reference if you have one that is unique across your whole book and never recycled. If it recycles, do not use it.
2. Make the pool readable from the identifier. You will be answering questions about these in two years, and ACME-2026-P4-L0117 tells you where to look.
3. Leave room. If you might ever tranche, the tranche prefix is added to the Loan ID and counts toward the same 64 characters.

6. Create your first pool

Register receivables then + New pool. A code, a name, a passkey, and whether the pool represents a whole asset or a tranche.

See Pools and passkeys.

7. Register a test batch

Do this with a handful of real Loan IDs, not your whole book.

Upload a loan tape or type the IDs. Every row is judged on its own, so a bad row never blocks a good one, and each comes back with its own verdict and transaction link. Accepted rows go on chain immediately; there is no STOKR approval step.

If you have no tape handy, the builder on Format and example files generates one carrying your own prefix.

8. Verify it the way your funder will

Go to spcr.io, paste in one of the Loan IDs and the pool passkey, and verify. No account is involved. That result is exactly what a funder sees; see it yourself once before you tell anyone it works.

Then the part that demonstrates the product: try to register the same Loan ID into a different pool. It is refused. That refusal is what you are buying.

9. Sell a pool

Transfer, choose the pool, choose the funder, review, confirm.

• Irreversible. Once a batch confirms on chain it cannot be undone.
• You may be asked to re-enter your password if you have not signed in recently.
• Large pools are processed in resumable batches and the screen reports how many receivables actually moved, rather than claiming all-or-nothing.

Send the funder the Loan IDs and the pool passkey so they can verify. If you registered into a tranche pool, send the loan tape SPCR generated at registration: it carries the prefixed identifiers and the passkey, so they can check the whole pool in one upload.

10. Integrating with your own systems

There is no API yet, so integration today is operational rather than technical. That is less of a constraint than it sounds, because SPCR only ever needs one column.

Where registration belongs in your process. As early as you can, and always before a receivable is offered to a funder. Registering after you have offered it means the uniqueness check never ran at the moment it would have mattered. The two sensible points are at origination, or at the moment a receivable enters the pool you intend to sell.

Register the whole book, not just what you are selling. The guard covers what is in the registry. A fully registered book cannot have a receivable quietly pledged twice; a partially registered one can, through the part that is missing.

What your systems need to produce. One column of Loan IDs, in .xlsx, .xls, .csv, .tsv or text, up to 5,000 rows at a time. If your loan origination or servicing system already exports a loan tape, that file works as it is: every other column is ignored. No mapping project, no field specification.

Who does it. Whoever runs your drawdown or pool-assembly process. It is a file upload and a review screen, not a technical task.

What to keep. Your pool codes, passkeys, Loan IDs and the identifiers derived from them. This is the one thing SPCR holds that you cannot rebuild from the chain, and it is what makes you independent of us. The loan tape offered after each registration contains it. See If SPCR disappeared.

If you want programmatic access, say so and say what you would call first. An API for registering, transferring and querying holdings is in development, and what gets built first is being decided by what people ask for.