Skip to main content

Security

Security (/settings/security) gathers the rules that protect the money leaving through the bank: what can be sent, from which accounts, to which payees, through which channels and within which limits. It applies only to payments and transfers — charges are out of scope.

The rules belong to the workspace: they apply to all of its companies at once, and the screen says so at the top ("Applies to every company in the … workspace."). With no workspace selected, it asks you to pick one.

Where it lives​

Limits tab of the Security screen

System menu → Security.

What the rules hold back​

Almost everything here acts when sending to the bank. Creating and approving bills stays free: a bill of a type that is off, from a blocked account or to a payee that is not allowed can be created and approved as usual — it just doesn't leave for the bank.

There are three exceptions, which act before dispatch:

  • the Channels tab, which has its own Create and Approve switches;
  • the Allow approvals at night switch, on the Limits tab;
  • the Approval Settings, which also go through Kobana (see Who can request changes).
note

A limit is not freed by editing or deleting a bill. What was already sent to the bank is recorded separately, with the amount sent: deleting the bill or changing its amount or payee afterwards gives nothing back to the limit. Only a payment that was canceled, rejected, reproved or failed at the bank stops counting.

Nothing takes effect right away​

Changes sidebar with one change ready to send

No change on this screen takes effect immediately. Every change becomes a request, which Kobana reviews and approves or denies. A security rule anyone could loosen on the spot would protect nothing.

In practice:

  1. You change whatever you want, on as many tabs as you want. The changes stay in a draft until you send them; once sent, the screen goes back to showing the values in force.
  2. Each change shows up in the Changes sidebar, on the right, with the value before and after and an Undo button per item.
  3. The Reason (optional) field explains the request to whoever reviews it.
  4. Send for approval sends everything as a single request. The button is always visible — pinned to the top of the sidebar and, on narrow screens, in a bar stuck to the bottom.
warning

The draft lives only in the browser. If you leave the page without sending, the changes are lost — the browser warns you before leaving.

While requests are under review, the screen shows the notice "1 request is waiting for Kobana's approval. The values on screen are the ones in force now." The new rule only takes effect once Kobana approves it.

Requests​

Requests screen

The Requests button, at the top of the page, shows how many are pending and opens the list of every request in the workspace, with search by requester or reason and a status filter.

ColumnWhat it shows
Date and timeWhen the request was sent
RequesterWho asked
ChangesWhat changes, item by item
ReasonThe text sent along
StatusPending, Approved, Denied or Canceled — plus Kobana's reason, when there is one
ActionsCancel, on pending ones

Cancel withdraws the request from review ("Kobana will no longer review these changes."). To ask again, redo the changes on the screen. Anyone who can create that request can cancel it — not only its author. Canceled requests stay on the list as history. Requests made from the Approval Settings screen show up here too.

More than one request can be pending at the same time. If two touch the same value, the second one to be reviewed is denied for conflict — the value it expected to change is no longer the same.

The tabs​

Limits​

Sets when it is day and when it is night and how much can be sent to the bank in each period.

  • Time zone — the clock for every rule: what is day, night, "today" and "this month". The search accepts a city, region or UTC; the Brazil zones come first, then Other time zones. Default: São Paulo.
  • Day and night hours — drag the two handles to set when day and night start, in 30-minute steps. The day starts at 05:00 at the earliest and ends at 22:00 at the latest. Default: day from 06:00 to 20:00, which is also the Central Bank default for Pix.
  • Night period, with two switches:
SwitchOn (default)Off
Allow approvals at nightApproving works at any timeThe approve buttons are blocked between the start of the night and the start of the day
Allow sending to the bank at nightSending works as usual, within the night limitsNothing goes to the bank at night — see Night sending off
  • Amount limits — a matrix with Payments (bank slips, taxes and utilities) and Transfers (Pix and TED) as rows, and Day limit and Night limit as columns, each with:
    • Per transaction — the maximum amount of a single dispatch;
    • Daily total — the sum of everything sent to the bank in the period, across every company in the workspace.

A blank field means No limit. The per-transaction limit can't exceed the daily total. With night sending off, the night limits have no effect.

Accounts​

Accounts tab

Chooses which accounts payments and transfers can leave from, and how much each one can send per day. Accounts are grouped by company; each has a switch for Payments and another for Transfers, each with its own Daily sending limit.

  • New accounts — the first row is the template: the settings each account gets when it is connected to the bank. It can be adjusted on its own row afterwards. Changing the template does not change accounts that already exist.
  • Accounts Not connected to the bank show up locked — there is nothing to send through them.
  • All enabled accounts applies the same limit to every enabled account in every company, with Apply to all. A blank field on that row keeps each account's current limit.

The account limit applies together with the ones on the Limits tab: when both apply, the lower one wins.

Payees​

Beneficiaries tab

Chooses which payees transfers can be sent to and how much each one can receive.

note

Transfers only — Pix and TED. Bank slips, taxes and utilities don't go through this rule: there, the money goes wherever the barcode says, and a supplier list would protect nothing. They are controlled in Operation types.

General rule, in two modes:

ModeWho receivesNew payees
Allow everyone and block some (default)Everyone except the ones you blockStart allowed
Block everyone and allow someOnly the ones you allowStart blocked

Each mode keeps its own list: switching from one to the other doesn't erase the other's marks.

The payee is identified by CPF/CNPJ, not by the person record. That's why the same supplier registered in several companies shows up only once ("Registered in 3 companies"), and its limits count across companies. The document compared at dispatch is:

  • the Pix key's, when the key is a CPF or CNPJ;
  • the payee's CPF/CNPJ entered on the bill, otherwise.
warning

For Pix by email, phone or random key, the system can't tell who owns the key: the document entered on the bill is what counts. If you want full rigor, turn those key types off in Operation types.

For each payee, the list shows the Allowed switch, the Daily limit, the Monthly limit and Transferred this month. The month is the calendar month, in the Limits tab's time zone. The search accepts a name or CPF/CNPJ, and the filter separates Allowed from Blocked. Documents the rule mentions but that no longer have a record show up as No active record.

All allowed applies the same limits to every allowed payee — on every page, or only those found by the search. A blank field on that row keeps each payee's current limit.

Operation types​

Operation types tab

A tree with everything that can be sent to the bank, with switches that turn each type on and off:

  • Payments — Bank slip; Utilities; Taxes (Federal: DARF, GPS, GRU and FGTS; State: ICMS and DARE; Municipal: ISS, IPTU and ITBI); Pix copy-and-paste.
  • Transfers — Pix by key type (CPF, CNPJ, email, phone, random); TED to a payee account or a judicial deposit.

Turning a group off turns off everything inside it; a group with some types on and some off shows in yellow. Types only turn on and off — there is no limit per type.

Types that are off can still be created and approved, but are not sent to the bank.

Channels​

Channels tab

A matrix with what can be done on each channel: Create, Approve and Pay ("Send to the bank").

Access channels — the way a person or a system gets in:

ChannelNote
DashboardThis web interface
Desktop app and Mobile appIn development — shown locked
APIIntegrations with your system
MCP - Artificial IntelligenceAI agents: Kadu, Kia and Others. Turning MCP on or off changes all three together
CLI - Command line

Origin channels — where a bill comes from without anyone typing it. They only create bills: Approve and Pay show as "Not applicable".

ChannelWhat it covers
ImportCSV spreadsheets
InboxDocuments received by email or upload
Invoices (NF-e)Bills generated from invoices
IntegrationsNibo, Fintera and upcoming ones

When a person generates a bill from an origin channel — say, from an invoice, in the Dashboard —, both channels must allow Create. Recurring bills follow the channel the series was created on. All channels turns an action on or off on every channel at once, except those in development. Lookups stay allowed on every channel.

warning

Default: Pay on only for the Dashboard. Create and Approve ship on for every access channel, and Create for the origin channels — but sending to the bank through the API, the CLI or AI agents requires an approved request. Those are the paths that can be automated, so they start closed.

Automatic dispatch after approval (see Approval Settings) uses the channel of whoever gave the last approval.

Users​

Users tab

Read-only. Lists who has access to the workspace, each person's roles and what those roles allow: Create, Approve, Pay and Force resend. Hover a mark to see which role grants the permission. The same permission covers payments and transfers.

To change it, use Change, which takes you to the person's roles in Members — the link only shows for those who can view members. Pending invitations and suspended users can't operate until they are active.

When a rule blocks​

When sending to the bank, the rules are checked in this order, and the first that fails decides: channel, operation type, account, payee (transfers only), night hours, per-transaction limit, period total, account daily limit and payee limits.

Nothing is rescheduled. A blocked bill stays where it is, with the reason in sight, and must be sent again once the rule allows it.

In the dispatch list​

In the Send payments to the bank dialog — the "Send to bank" list in Payables —, a bill held back by a rule that depends only on the bill itself shows disabled, with the reason:

Reason on the listWhat to do
Channel not allowed to dispatchRequest Pay for the channel, on the Channels tab
Operation type turned offRequest the type, in Operation types
Account blocked for this operationRequest the operation for the account, in Accounts
Beneficiary not allowedRequest the CPF/CNPJ be allowed, in Payees
Night dispatch blockedWait for the day period to start
Above the per-transaction limitRequest a higher limit, in Limits

The limits that depend on what has already been sent — period total, account daily limit, payee daily and monthly limits — show as a warning, and the row stays selectable: "Would exceed the period limit", "Would exceed the account's daily limit", "Would exceed the beneficiary's daily limit", "Would exceed the beneficiary's monthly limit". Hover to see the limit, how much was already sent and how much is left.

In a batch send, bills go in due-date order; once a limit is reached, the following ones that would exceed it are not sent, and the result lists each one with its reason.

If the automatic dispatch was refused by a rule, the row carries the Automatic dispatch blocked badge.

Night sending off​

With Allow sending to the bank at night off:

  • nothing goes to the bank between the start of the night and the start of the day — neither through the button nor through the automatic dispatch after approval;
  • the list shows the notice "Bank dispatch blocked until 06:00" (with your hour);
  • what was approved at night is not sent on its own in the morning: it stays on the list and must be sent again during the day period.

Batch held at the bank​

A payment may be created at the bank at the end of the day while the batch's automatic approval falls in the night period. In that case the batch is not approved: it is held at the bank.

  • On the bill, the payment card shows the "Held at the bank: night dispatch blocked" badge.
  • On the dispatch list, those bills show up in the Held at the bank section.
  • The Approve at the bank button — on the card and in the section — only works during the day period. It checks the rules again, approves the batch and resumes tracking the payment.

"Refresh status" and the automatic tracking do not approve a held batch.

On approval​

With night approvals off or Approve off for the channel, the Approval screen shows a notice and disables the approve buttons. Rejecting is never blocked.

The same screen warns, on each bill, when it won't be able to be sent as it is ("Sending blocked by Security") — so whoever approves knows the release must be requested.

On creation​

With Create off for a channel, the bill is not created: "The … channel can't create bills. Ask for it to be enabled in Security." For imports and integrations, the reason is recorded in the run's report, and a recurrence created through a channel that is off stops generating occurrences while it stays off.

Who can request changes​

WhoWhat they can request
OwnerAny change, on every tab
Whoever has the Approval settings permissionOnly changes to the approval settings, through the Approval Settings screen
Other roles (Admin, Viewer…)None: they see the rules, and the sidebar warns "Only people allowed to request security changes can send requests."

By default, only the Owner requests security changes — not even the Admin. The decision is always Kobana's.