Skip to main content
Your institution can run two core engines on one ISPB. An account at that ISPB then belongs to one of the two cores. A TED from a Bank Transfer account to an account that the other core holds is a cross-core TED. The plugin does not send it to the STR. It sends the credit to the other core through the JD Courier relay. The other core sends its cross-core TEDs to Bank Transfer through the same relay.

​
When a TED is cross-core

The tenant policy onus.shared_ispb_gate_enabled (default false) says that your ISPB is shared with another core. When it is true, or unreadable, the plugin asks the JD Courier ownership map who holds the recipient account of each TED to your ISPB: With false, a TED to your own ISPB is a P2P, and the plugin does not ask the map.

​
Send a cross-core TED

A cross-core TED uses the same two calls as a TED OUT: Initiate Transfer and Process Transfer.
  1. Initiate. The plugin prices the transfer as a TED OUT: the fee is charged on top of the amount, and the recipient gets the whole amount. In native fee mode, a fee package that takes the fee out of the amount is refused with 422 BTF-3002. Like a P2P, a cross-core TED ignores the TED OUT operating window.
  2. Process. The plugin checks the holder of the recipient account again. It holds the amount plus the fee on the sender’s account, with the ledger account @intercore as the counterpart. Then it sends the credit to the other core through the JD Courier.
The answer decides what happens to the hold: The reconciliation worker resends a credit with an unknown outcome, inside and outside the TED OUT window. When the other core credits the recipient, the plugin commits the hold. The plugin keeps the hold and parks the transfer for an operator in these cases:
  • After an attempt whose outcome was unknown, the other core refuses the credit, or the JD Courier answers that the holder of the recipient account changed.
  • No answer arrives within 24 hours.
  • The release of the hold does not finish.
A parked transfer stays PROCESSING, with reconciliation status MANUAL_REVIEW. Find it with List Pending Reconciliation. An operator resolves it as a TED OUT with Resolve Transfer Reconciliation: SETTLE commits the hold, and REVERT releases it. Before it places the hold, /process refuses the transfer in these cases:
  • 422 BTF-4003: the holder of the recipient account changed after the initiation. The transfer is FAILED.
  • 503 BTF-4000: the ownership map does not show the sender’s account as held by this engine. Send the confirmation again later.

​
Receive cross-core credits

The other core sends its cross-core TEDs to Bank Transfer through the JD Courier. The plugin books each one on the recipient’s ledger, with no fee:
  • A credit debits @intercore and credits the recipient the whole amount, on the CROSS_CORE_IN binding.
  • A return of a cross-core TED that you sent debits @intercore and credits the original sender, on the CROSS_CORE_RETURN_IN binding. A return can be partial. The plugin refuses a return above the amount not yet returned.
Both are transfers of type CROSS_CORE_IN with status COMPLETED, and both fire transfer_incoming.completed.

​
Set up cross-core transfers

  1. Set the tenant policy onus.shared_ispb_gate_enabled to true through the Admin API.
  2. Connect the plugin to the JD Courier with the JD Courier variables. Set COURIER_ACCOUNT_CLAIMS_ENABLED to true, so that the plugin claims the accounts of this engine on the ownership map.
  3. Create an account with the alias @intercore in each ledger that sends or receives cross-core TEDs. A credit from the other core debits it, so allow an overdraft on its balance.
  4. Add the CROSS_CORE_OUT, CROSS_CORE_IN, and CROSS_CORE_RETURN_IN bindings to the ledger routing. Each ledger with a CROSS_CORE_OUT binding also needs a CROSS_CORE_RETURN_IN binding.
  5. Set up the other core as the JD Courier pages describe.
Before you move traffic, call Check Ledger Routing Readiness. It lists each missing binding.