Skip to main content
JD Courier lets two or more core banking engines share one JD Consultores channel and one ISPB. Each core banking system that processes the money movements of its own accounts is an engine. Your existing core is one engine. The Lerian stack is another. JD gives each participant one channel. On SPB, a read from the channel removes the message. On Pix, JD calls one address. So two engines cannot share the channel directly. The Courier sits between JD and the engines. JD sees one participant, and each engine receives only the messages that belong to it.

​
When you need it

You need the Courier when your institution runs more than one engine on the same ISPB and the same JD channel. The most common case is a migration. You move accounts from your existing core to the Lerian stack in waves, and both engines operate at the same time. The Courier covers two rails:
  • SPB (TED). The Courier reads the SPB messages that JD holds for your institution and delivers each one to its engine. Engines send their own SPB messages to JD through the Courier.
  • Pix. JD sends the inbound Pix calls of your institution to the Courier. The Courier delivers each call to its engine and relays the answer of the engine to JD. The Courier does not send Pix requests to JD.

​
What the Courier guarantees

  • One owner for each account. An explicit ownership map tells the Courier which engine owns each account. The map accepts one owner for each key. The Courier delivers each financial message to one engine.
  • Unrouted messages stay retained. When the Courier cannot route or deliver a message that it stored, it retains the message. The Courier does not credit a retained message and does not return it to BACEN. Your operator sees each retained message with its reason and its age.
  • A message retained for a routing or delivery cause leaves through the routing decision. When a routing or delivery cause clears, the Courier routes the message again by itself. An operator can also request a new routing decision, with a reason. The operator never chooses the engine.
  • An account validation that the Courier cannot route is refused in the same call. JD receives AC03 or AB09. A validation comes before settlement, so no money moves.
  • Moving an account is a configuration change. An operator moves an account from one engine to another through the API. The move requires a reason, and the Courier records it in an audit history.

​
What the Courier does not do

  • The Courier does not create payment messages. Every SPB message that the Courier sends to JD comes from an engine.
  • The Courier does not access a ledger and does not hold balances. Each engine keeps its own books.
  • The Courier does not decide whether an engine accepts or refuses a payment. It relays the answer of the engine.

​
How it runs

The Courier runs in your own cloud (BYOC) or on Lerian Cloud, where Lerian operates it. It uses its own PostgreSQL database. One binary runs in four roles, and the Helm chart runs each role as its own deployment: The setup is in Deployment and configuration.

​
Where to start

  1. How routing works: the ownership map, the routing rules for each rail, and what happens to a message that the Courier cannot route.
  2. Connecting an engine: what the team of each engine changes and implements to work behind the Courier.
  3. Deployment and configuration: the Helm chart, the four roles, and the environment variables.
  4. Daily operations: the work of your operator, from retained messages to account moves.
  5. The API reference and the JD Courier error list.