Domestic wires

A domestic wire sends funds from a pocket to a US bank account your customer has registered and verified with Jiko. Wires are credit-push only and settle within a bank business day; there is no return window and no equivalent of an ACH return.

Required end-user disclosure. When you build wire entry screens in your own UI, you must show your end users the following: "By using this service, you hereby acknowledge that sending wires to third parties presents an increased risk of fraud, and that as per the terms of your Commercial Bank Account Agreement (the "Agreement"), you agree that our security measures are commercially reasonable methods of providing security against unauthorized Funds Transfers, and that you shall be bound by any request for a Funds Transfer received by the Bank, whether or not authorized, issued in your name and accepted by the Bank in compliance with the security measures."

POST /api/v2/customers/{customer_id}/counterparties/

A wire counterparty carries:

FIRST_PARTY means the destination account belongs to your customer. THIRD_PARTY means it belongs to someone else — a supplier, a landlord, a contractor.

unverified is not a shortcut for skipping verification on a customer's own account. A first-party destination must be verified by one of the other methods.

Wait for the counterparty.status.linked webhook before originating. It carries counterparty_id and customer_id.

Partner systems:

1. Decide ownership_type. It constrains which verification you may use, and it is the field that decides whether unverified needs a feature flag.
2. Register the counterparty with type: "wire" and a verification block. For supporting_documents, upload the documents first — the request takes their IDs, at least one.
3. Wait for counterparty.status.linked. FAILED, UNLINKED and CLOSED are terminal; recovering means registering a new counterparty.
4. Create the wire with your own wire_id and a created_by.
5. Track it by wire_id — through the webhooks, the wire resource, and filter[wire] on the transaction feed.

POST /api/v1/jiko-accounts/{account_id}/wires/

The endpoint returns 201 with an empty body. If you do not supply an ID, Jiko generates one and you have no direct way to learn it — you would have to list wires and match on amount and time. Supplying your own makes the call idempotent and gives you the handle for every subsequent lookup and every webhook.

created_by is recorded on the wire. Where a wire requires approval, Jiko also records the approvers and returns them as client_verifiers.

SUCCESS means the wire has been sent, not that the beneficiary bank has credited it.

Payload: jiko_account_id and wire_id.

transfers.wire.out.processing can fire more than once as a wire moves between internal stages, all of which collapse to the same event. Treat it as "still in progress" and rely on success or rejected for terminal outcomes.

GET /api/v1/wires/ is cursor-paginated and accepts direction=OUTGOING, customer_id and pocket_id. An outgoing wire returns status, amount, pocket_id, counterparty_id, client_verifiers and wire_tracking_info.

Once the wire is exported, Jiko assigns the network identifiers and exposes them in wire_tracking_info:

• uetr — the end-to-end reference that follows the payment through every institution in the chain. This is what a beneficiary's bank asks for when tracing a payment, and what you should surface to a customer chasing one.
• imad — the clearing network's input reference.
• instruction_identification and end_to_end_identification — party-assigned references on the ISO 20022 message, up to 35 characters each.

These are populated when the wire is sent, so they are absent while the wire is PENDING.

An outgoing wire appears in the transaction feed as type: "WIRE" with direction: "DEBIT", carrying wire_id, counterparty_name and reference_number.

Resolve a wire to its transaction with filter[wire], which accepts one or more wire IDs. filter[type]=WIRE narrows to the rail, and the usual amount_from / amount_to / time_booked_from / time_booked_to / time_settled_from / time_settled_to filters are available.

The wire resource and the transaction serve different purposes: the wire resource is the payment as the network sees it, the transaction is the money as the pocket sees it.

Inbound domestic wires address a portal directly. The beneficiary account number on the wire is the portal's account number and the receiving bank is Jiko's domestic bank. Jiko resolves the portal from the account number and checks that the routing number on the wire matches the portal's; a mismatch stops the wire from being attributed automatically.

Get the details to hand a payer from:

GET /api/v2/pockets/{pocket_id}/portals/{portal_id}/funding-instructions/

The DOMESTIC_WIRE instruction returns the receiver bank (routing number, name, address) and the beneficiary (account number, the customer's legal name, address), already populated. Do not assemble them yourself from the portal's raw fields.

A wire-enabled portal returns both a domestic and an international instruction, and they are not interchangeable — the beneficiary account differs between them.

Inbound events are transfers.wire.in.success and transfers.wire.in.rejected, with a payload of jiko_account_id and wire_id. Where Jiko cannot resolve the beneficiary to a pocket, no event fires and no transaction exists.

Wires post within a bank business day. A wire arriving outside banking hours, at a weekend, or on a bank holiday posts on the next business day, not on receipt.

• International wires
• Create wire — full request schema
• Counterparties
• Webhooks