Client Staking on Assets the Institution Already Holds in Custody

An institution that already lets clients buy and hold crypto is sitting on idle proof-of-stake assets and a client base asking what those assets earn. Staking answers that without a new asset class, a new distribution channel or a new authorisation: the same custodied balance is delegated to validators, protocol rewards accrue against it, and the institution earns a disclosed commission on those rewards. The validator operation is rented from a staking provider. What cannot be rented is the record of which customer earned what, on which date, at what value, because that record is what a statement, a tax return and an audit are built from.

The sequencing evidence is unusually clear: PostFinance brought trading and custody live with Sygnum in February 2024 and added Ethereum staking about eleven months later, in January 2025. The timing is not arbitrary. Since ESMA's Q&A of 20 June 2024, the regulatory route is settled enough to plan against - staking-as-a-service sits inside MiCA as an activity ancillary to custody, rather than needing its own authorisation. And from 1 January 2026 the EU's DAC8 obligations took effect alongside the OECD Crypto-Asset Reporting Framework, so a reward stream that used to be an internal accounting matter is now reportable data with a filing date attached.

If you already run crypto trading and custody in your own channel, hold proof-of-stake assets for retail or wealth clients, and are roughly a year past that launch - yes, and the sequencing evidence says this is when institutions reach it.

Probably not if your custody is not yet live (start there), if your client balances are mostly stablecoin rather than proof-of-stake assets (a lending structure fits better), if your clients want to borrow against holdings rather than earn on them, or if you have promised same-day access to holdings - protocol unbonding periods and exit queues are not something integration work removes.

• The reward record is the part you build. Three providers have named production references at the validator and instruction-construction layer - Kiln, Figment and Blockdaemon - but none supplies per-customer reward attribution against an institution's own ledger, and no proven provider for that layer was identified at all. It is where most of the build cost and time will go, because there is nothing to buy.
• The staking provider authors the instructions you sign. A compromise there does not need custody access to cause a loss. In September 2025 roughly 192,600 SOL - about $41M - was drained from SwissBorg's Solana earn product through Kiln's interface, and SwissBorg reimbursed its customers from its own treasury. Independent verification of every instruction before signing, together with exposure limits, is treated here as essential.
• The liability sits with the institution by default. Staking is not a service MiCA lists, so there is nothing to apply for; ESMA's Q&A of 20 June 2024 brings it into scope as an activity ancillary to custody. MiCA Art. 75(8) leaves the institution liable for losses of client crypto-assets attributable to it, and ESMA reads that to cover losses arising from staking. Explicit per-customer consent to stake is required, because staking changes when the client can reach the asset.
• Reward events became reportable on 1 January 2026. DAC8 and the OECD Crypto-Asset Reporting Framework took effect in EU member states, with self-certification collected from 2026 and first reports to domestic tax authorities due in 2027.