Hierarchies
Every large company has its own way of structuring its business. A global bank, for example, has a corporate headquarters with global regions, which break down into countries that have states, that have cities where you find branches.
To support a variety of complex organizational structures, Pismo's corporate banking solution extends the Pismo platform by introducing a flexible, generic hierarchy that can accommodate any type of structure you need. A hierarchy is created under a single organization (Org) and is divided into levels. Levels are categories, such as Region, Country, or City, such as North America, Brazil, or Chile. Each level contains divisions. At the City level, for example, you might add the divisions London and Glasgow. Level is the primary element and may contain one or more divisions.
Hierarchies are typically organized by geography or corporate structure. Beneath the top level, you might define levels such as region, country, city, and branch. Another pattern is a corporate hierarchy in which a parent company like ABC Corp has subsidiaries such as ABC Services, ABC Construction, and ABC Technologies, each with its own business units.
| Level | Description |
|---|---|
| 1: Region | Divisions in Level 1 could include: North America; South America; Europe, Middle East, Africa (EMEA) |
| 2: Country | Country divisions would be countries, such as Mexico, Brazil, Argentina, France |
| 3: City | Divisions in level 3: London, Manchester, Buenos Aires, Bariloche, etc. London and Manchester are child divisions of Brazil. Buenos Aires and Bariloche are child divisions of Argentina. |
Every hierarchy has a unique ID, as does each level and division. These IDs are used when creating account families. Each level has an index (0, 1, 2, ...), with 0 representing the Headquarters level or top level, and a description.
Create hierarchies, levels, and divisions
You set up levels using the Create hierarchy endpoint. After creating levels, use their IDs to add divisions using the Create division endpoint. A division is also used in scenarios related to account creation, defining business holidays, program binding, and so on.
A division element (for example, Country = United Kingdom) can have a parent/child relationship with a division at a different level. For example, London is not only a division element for the city level, it could also have United Kingdom as its parent division at the country level.

Parent/child relationships between divisions are represented by the red arrows.
Bind a program to a division
You bind one program set to a division, and accounts inherit that set through the division hierarchy when you update the division using the Update division endpoint. A program set defines the programs available to a division, and each division is associated with exactly one set. A subsequent call to this endpoint replaces the current program set with a new one, whether you are adding programs, removing programs, or switching to a different set entirely. Note that an account in the program set can belong to only one division. Refer to Divisions for more details.
About program set
A program set is the group of
program_idsassociated with a division. When you create or update a division, you define which programs are allowed for that division.For details about programs, refer to Core objects.
Other hierarchy endpoints
- Get hierarchy: Enables you to view hierarchies by ID.
- Get division: Gets information about a specific division.
- Further, you can optionally update a division with certain configurations and behaviors. You can define a division's holidays, for example, and forbid transactions on those days. If your division has no defined holidays, every day is treated as a working day.
Holiday definitions
- Holidays are defined as configurable nonworking days that let you allow or deny transactions. Only the days you define in the holiday calendar can block transactions, and you can mark any day—including weekends or national or regional holidays—as a holiday. Refer to Create holiday calendar for details.
- By default, weekends are nonworking days, but they do not automatically deny transactions unless you configure them as holidays in your division's calendar. If you do not define holidays, everyday is considered a working day, including weekends.
- All accounts created within that division inherit the holiday configuration.
- If a transaction occurs on a holiday defined for a division or any parent division, it is denied because holiday settings are inherited through the hierarchy.
Updated about 4 hours ago