top of page

Process Flow for Bond
Issuance on DLT

Stage 1 : Process Flow for Bond Issuance on DLT

a2.png
  • Regulators will interact with FAST to create the issuer's profile for launching the bond.

a3.png
  • FAST will process the bond approval process, ensuring Shariah compliance.

  • FAST will log in to set up the bond issuance parameters.

  • The issuer can log in and access the bond bidding/subscription API.

  • Assume: Bidding custodian banks will operate on either "FOP" basis or "DVP."

  • Assume: Central banks will swap RMDC with fiat currency to participate in the DLT bond process.

  • Assume: One of the custodian banks requested and received approval to fractionalize the bond for retail investors.

  • Assume: Retail clients will participate through custodian banks by swapping RMDC with fiat currency.

  • Assume: All regulators, including BNM, RENTAS, FAST, custodian banks, retail clients, and the issuer, will utilize the concept of an identity wallet as a KYC-proven ID for access and participation.

Note :

An essential requirement is the generation of a settlement instrument, "RMDC" (CBDC), to replace fiat currency for settlement.

Stage 2 : Creation of the Bond in the Database. DLT Deployment.

a5.png
  • FAST creates the bonds for bidding, specifying the starting time and ending time digital term sheet

a6.png
  • The tenure of 12 months is set within 40 minutes, with a 20-minute interval for sukuk coupon payment.

a9.png
  • After the bond is created, a countdown to the bidding period will appear on BNM/Regulator screen, along with bond details, on the interfaces of all authorized participants.

a12.png
  • Regulators can broadcast any remarks or notices to the relevant parties' screens.

Stage 3 : Bidding

a10.png
  • Bidding commences as qualified Custodian banks participate in bidding for the bond and obtain pre-approval for fractionalization of the bonds for retail.

  • Retail clients are not allowed to bid directly; they can only participate through their respective banks.

a11.png

  • The system incorporates simple computation mechanics, and additional logical conditions can be applied as needed. At this stage, the bid with the lowest coupon rate will be given priority. In the event of tied rates, bids with earlier timestamps will be awarded or distributed based on this algorithm.

Stage 4 : Completion of Bidding Process

a13.png
  • The bidding period concludes, and the list of successful bidders is made visible to all authorized parties, including central banks, except their respective retail clients.

  • When applicable, a multisig wallet is implemented for any necessary DLT executions.

  • All authorized parties can access the bidding process details, including the list of successful bidders and information on oversubscription, through their respective screens. Additionally, an API is available for publishing any desired oversubscribed information.

Stage 5 : Deployment of Bonds and Distributions/Settlements in DLT

p5.jpg
  • The bond is deployed by RENTAS or any authorized regulators. Upon deployment 5 approval transactions will be required:

- Approval for Bond generation

- Approving RENTAS to send RMDC to the smart contract

- Distribution of the bonds to custodian banks

- Approve the fractionalisation or retail bond distribution contract

- Distributing of the bonds to retail customers

a14.png

- Approval for Bond generation

- Approving RENTAS to send RMDC to the smart contract

- Distribution of the bonds to custodian banks

- Approve the fractionalisation or retail bond distribution contract

- Distributing of the bonds to retail customers

a16.png

  • Upon deployment, the maal blockchain generates a smart contract address, which is then published by regulators. All successful bidders must import the bond token address into their wallets to receive the bond immediately or at a later time.

a17.png

  • For fractionalized retail bonds, the additional distinct address denoted by the signed "r" in front of the Bond Symbol must be added to the retail clients' wallets.

a18.png

  • After adding the "Bond Token" address, all successful bidders, including Custodian Banks and Retail Clients, will have the participated bond units in their respective wallets.

  • Wallet operations can be authorized individually or with an MPC key or multi-signature (if multiple personal authorizations are desired).

a20.png

  • All bond details, including settlements between RENTAS and the issuer, RENTAS and Custodian Banks, Custodian Banks and retail clients (with unlimited participants), and distributed bond information, are accessible based on respective authorization levels.

Stage 6 : 1st Semi-Annual Coupon Payment

a21.png
  • Assume that the issuer has the required RMDC stored in a smart contract for profit sharing of sukuk. The DLT system will record the transaction of the payment between the issuer and RENTAS.

  • RENTAS will redistribute the RMDCs that are due to the successful bidders.

p6.png

  • 1st Transaction – Distributing the profit sharing to CB’s

  • 2nd Transaction – Distributing the profit sharing to retail investors

a22.png

  • All sukuk holders' wallets will receive the semi-annual profit share in RMDC.

  • All transactions are recorded in the DLT ledgers with transaction details and IDs.

Stage 7 : (2nd Semi-Annual Coupon Payment)

a23.png
  • Same as stage 6 above.

Stage 8 : Bond Maturity and Settlement Process

a24.png
  • The issuer must redeem the bond and settle with RENTAS by sending RMDC.

a25.png

  • RENTAS will swap or redeem the bond from wholesale and retail participants with RMDC.

a26.png

  • The issuer's dashboard will show no remaining sukuk obligations.

Notes:

  • The entire process and events that took place can be verified and seen in the DLT and ledgers.

  • The smart contract created by FAST and executed by RENTAS will have a zero balance for audit purposes.

  • RENTAS can always access the smart contract through its user interface (UI) or user experience (UX).

  • The issuer's dashboard will show no remaining sukuk obligations.

  • The entire process in the DLT will be permanently recorded and immutable.

  • Only authorized parties can view the subscriber IDs.

bottom of page