> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Cross-core transfers > Send a TED to an account that the other core of your institution holds, and receive its credits, through the JD Courier relay. 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](https://docs.lerian.studio/en/interfaces/jd-courier/what-is-jd-courier.md) 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: | Holder of the recipient account | Result | | - | - | | This engine | A [P2P](https://docs.lerian.studio/en/interfaces/ted-jd/ted-p2p.md) | | The other core | A cross-core TED, type `CROSS_CORE` | | No engine | Refused with `422 BTF-4003` | | The map does not answer | Refused with `503 BTF-4000`, `502 BTF-4001`, or `503 BTF-4002` | 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](https://docs.lerian.studio/en/reference/interfaces/ted-jd/initiate-transfer.md) and [Process Transfer](https://docs.lerian.studio/en/reference/interfaces/ted-jd/process-transfer.md). 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: | Answer | Hold | Transfer status | | - | - | - | | The other core credited the recipient | Committed | `COMPLETED` | | On the first attempt, the other core refused the credit, or the credit did not reach it | Released. `/process` answers `422 BTF-4005` | `REJECTED` | | The outcome is unknown, for example after a timeout | Kept | `PROCESSING` | 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](https://docs.lerian.studio/en/reference/interfaces/ted-jd/list-pending-reconciliation.md). An operator resolves it as a TED OUT with [Resolve Transfer Reconciliation](https://docs.lerian.studio/en/reference/interfaces/ted-jd/resolve-transfer-reconciliation.md): `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](https://docs.lerian.studio/en/interfaces/ted-jd/ted-environment-variables.md#jd-courier). 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](https://docs.lerian.studio/en/products/midaz/balance-overdraft.md) on its balance. 4. Add the `CROSS_CORE_OUT`, `CROSS_CORE_IN`, and `CROSS_CORE_RETURN_IN` bindings to the [ledger routing](https://docs.lerian.studio/en/interfaces/ted-jd/ted-configuration.md#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](https://docs.lerian.studio/en/interfaces/jd-courier/what-is-jd-courier.md) pages describe. Before you move traffic, call [Check Ledger Routing Readiness](https://docs.lerian.studio/en/reference/interfaces/ted-jd/check-ledger-routing-readiness.md). It lists each missing binding. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.