 |
 |
 |
|
|
Computer software for General
Insurance brokers, agents and underwriting managers.
Frequently asked questions about:
|
|
|
|
|
|
|
"Is Inandrias a client or policy based system?"
Inandrias is primarily a client based system. This means that transactions are normally processed against a policy owned by a client. Schemes processing is an exception to this rule.
"How
much client data must be captured before a policy can be processed and a debit raised?"
It is possible but not recommended to capture only three pieces of information about a client so that a policy can be captured, processed and a debit transaction raised.
"OK. How long would it normally take to capture all client data, basic policy information and raise a client debit?"
This depends on at least two factors:
- The availability of the information to be captured.
- The speed and experience of the person doing the capture.
Assuming these conditions are satisfactory then the whole process of capturing all client data, basic policy information and raising a debit should not take more than twenty minutes of a capturer's undivided time.
"What is the 'Client service team'?"
The various personnel involved in servicing each client, for example: Account executive, Commission agent, Claim handler(s).
"How many risk addresses can Client's have?"
In Inandrias risk addresses are referred to as Situations. There is no practical limit to the number of risk addresses or Situations for each Client.
"What is the reason for storing client's banking details?"
This information is absolutely mandatory for Underwriting Managers and Insurers that collect premium using auto debit facilities. The accuracy of client banking information is also of paramount importance as it can be very costly to process unpaid debits.
"Can Inandrias manage Client settlement terms and discounts?"
The short answer is "Yes".
Of course, this does not preclude the fact that the premium must be paid to the insurer in the time frame that is normally prescribed by law. This means that the Broker or Underwriting Manager is "funding" the client for terms given to the client that continue after the premium has been remitted to the Insurer.
"So is it possible to raise a monthly fee as part of the debit to the client but not credited to the Insurer?"
Yes. Fees of this nature can be created as Sections or Classes to the policy. A percentage field on the Section type record determines how much of each Section or Class is paid over to the Underwriter. Normally this is 80% in the case of non-motor Sections and 87.5% for the motor Sections. This percentage can be set to 0% for a Broker fee or 100% for an Insurer fee.
"Can a Client be debited for non-policy related services?"
Yes. This is called Fee processing and it enables the Broker or Underwriting Manager to debit Client with an agreed amount including taxes like VAT. There is no corresponding Insurer credit raised. Currently it is not possible to include a Commission Agent in a Fee debit.
"Can a policy be underwritten by more than one Insurer?"
Yes. Any number of collective insurers can be stored against a single policy. One of the insurer's must be nominated as the lead insurer and the sum of all the insurer's risk or cover percentages must be 100%. Each insurer's policy number can also be stored on the policy.
"What is the calculation priority on a commission agent all about?"
Essentially it is to do with the fact that some agents are registered to pay taxes (like VAT) while others are not. In Inandrias the tax man is also treated like an agent (he takes a bite out of the commission) there are actually three types of agent.
Firstly those that pay over taxes, the tax itself and then those for whom the Broker pays the tax by default. This heirarchy is determined by the calculation priority that is stored on the relative agents.
"What other types of agent's are used by the system?"
The obvious ones are Account Executive, Account handler and Claims handler. These are used mainly for reporting purposes. Users can create any type of agent they wish and where relevant create report structures to analyse their client's policies and transactions through them.
"How easy or difficult is it to assign assets to a policy?"
There are two main methods of putting assets on a policy after opening the Premium Allocation tab. The Classes or Sections displayed in this form are allocated to the policy based on the product and insurer that were used when the policy was created.
The Premium Allocation form can simply be completed for each Section or Class that the client has requested cover for. This would normally be adequate for the Insurance Broker or Agent.
A more in-depth method involves opening the Schedules tab for each Section or Class on cover and completing the fairly complex forms with information normally required by an Underwriting Manager or an Insurer.
"What sort of information is captured when using the Schedules option to put client's assets on a policy?"
The standard set of Schedules that come with Inandrias closely follow the Multimark III policy wordings. But with adequate training and practice users can create their own policy wordings complete with formulae to calculate premiums from asset values and other criteria.
Underwriting Managers or Insurers should have at least one 'superuser' with this knowledge and capability.
"Can a 'superuser' also modify the way that policy schedules and summaries print?"
Absolutely. This allows each organisation to put their own 'brand mark' on the system. We all know how important this is in today's competitive environment. Buying decisions are more often made based on how effective and appealing an insurance proposal is when presented to prospects.
"How does the system cater for the various types of transactions that can be raised against a client? New business, Renewals, Debit/Credit Endorsements and reversals when cover not taken up."
Originally Inandrias tried to determine the transaction type for each debit or credit being raised but in certain indistinct cases managed to get it wrong. Nowadays the system 'suggests' the transaction type and gives the user the facility to change it.
"What if the user gets it wrong? What recourse is there, if any?"
Each user's log in name is recorded on all records in the system added or modified by them. This way errors can be identified quickly and users corrected where necessary.
Erroneously processed transactions can be completely mirror reversed before they are captured again, hopefully correctly.
"Is it possible to load a policy against the wrong client? If so, what can be done about this?"
Unfortunately the system cannot know that the next policy being loaded is not for this client. The policy "Move" function facilitates moving a policy to another client. This operation also moves all transactions, situations and so forth related to the policy being moved.
"Is there a standard set of correspondence that can be sent to clients or other parties?"
There is, but the standard set is completely amendable by any user having the authority to do so. Such users can also create new letters, memos, faxes or emails and even delete redundant ones.
"Can the system prepare and submit debits in electronic format for a bank or clearing bureau?"
Yes. Selection criteria is by Insurer, by Product code and/or by Payment Method. An edit list reviews the selection to be processed. A facility also exists to process receipts from Underwriters for debits that they have collected on a Broker's behalf. These transactions are known as direct debits.
"Does Inandrias store information about Client's assets and liabilities?"
Yes. The Schedule processor is used to capture information about the Insured's assets so as to correctly rate the premium and, where necessary, process or repudiate claims based on cover in place at the date of loss. This powerful tool is user amendable and can be used to duplicate insurer’s policy wordings or simply produce underwriting summaries.
"Are Products synonymous with Insurers in Inandrias?"
Insurers are related to Products but are not necessarily exclusive to them. For example, in South Africa, the Multimark III product is offered by most Insurers but Aviation and Marine products are offered by specialist companies and their products are often unique.
"Can Inandrias be used to debit a client for product or service provided solely by the broker?"
Yes. Obviously the onus is on you to make sure that the sale of such product by you is acceptable to the country or state's authority where you operate and that it does not contravene any law.
The best example would be something like an anti-theft device. This could be added to the policy as a "Section" with 100% commission (i.e. all for the Broker's account). Remember to remove the Section from the policy before renewal or you may debit the client again and that may make him grumpy!
"In Australia many people are paid fortnightly. Can Inandrias debit clients every two weeks if necessary?"
It is possible to set up a pay method to do this though so far this particular permutation has not been used by any of our clients as far as we know.
The standard Pay Methods supplied with the system are:
- Annual
- Annual paid monthly
- Biannual
- Quarterly
- True monthly
- Monthly Insurer collects
- Single premium (for travel coveretc.)
"What's the worst that can happen if a user puts the incorrect Payment method on a policy?"
The worst that can happen is to embarrass your client. All FAP's (Future Annual Premiums) are stored as that: annual premiums.
If your client elected to pay quarterly and your staff loads the policy as Annual then your client will be debited once for the full premium instead of four times for a quarter of the premium.
When your client points out the mistake you simply reverse the debit, correct the PayMethod field on the policy and sections, then raise the correct debit.
"Can Inandrias process Aggregate Excesses?"
Not yet.
"Can Inandrias be used to operate a Lloyd's binder?"
Absolutely. In fact Inandrias is ideal for such an operation because of
- Registration, settlement and in-depth Claims reporting
- Management of collective premium and risk share by the owners
- Flexible Product definition and transacting
- Unlimited, customisable Schedule wording processes
|
|
|
|
|
|
|
Schemes
|
|
"What is the Inandrias definition of a Scheme?"
This is a hugely important question.
The broad definition is that a Scheme is any group of insured entities or assets whose information is managed collectively and can be supplied from a single source.
This applies to but is not limited to:
- Financial institutions
- Employers
- Product or Service suppliers
- Geographic locations (shopping malls etc.)
"What is the difference between a Scheme and a non-scheme policy?"
A Scheme policy "belongs" to a Scheme client and is automatically assigned to a specific Product that is identified by the Scheme itself.
Scheme policies can be processed individually just like other policies. This functionality is necessary for the registration of claims or any manual amendment of policy holders' or their assets' details.
"Does the Scheme renewal process automatically re-rate sections based on user supplied formulae or data?"
Yes. Most rating permutations are catered for. It fairly simple to code almost any renewal rating process. This is normally done free of charge if the modification is deemed to add value to
Inandrias.
"Does the Scheme renewal process take cognisance of any claims and adjust Claim Free Groups or other data accordingly?"
The default change to Claim Free Group values at renewal is to decrease the CFG on Motor policies by two points if the Insured has had a non-glass claim within the past twelve months.
The standard business rule can be extended with relatively simple coding to cover almost any contingency free of charge if the modification is deemed to add value to Inandrias.
"How many Insurers can a Scheme relate to?"
There is no limit to the number of Insurers that can be on risk for any given Scheme either in an Insurer per policy or a collective mode.
"Can Scheme policies have Schedule Wordings?"
Yes. Ideally these are maintained by the Scheme sponsor in the information supplied periodically (normally monthly) to the Broker's Scheme manager for processing into Inandrias.
"What is the difference between a Scheme and a Product?"
A Scheme is really an enhanced Product. A Product in Inandrias is a collection of Sections or Classes related to one or more insurers. A Scheme is also a collection of Sections or Classes related to one or more insurers further related to a "master" Client record and many Client/Policies in the Scheme.
"Is it possible to convert a group of Clients or Policies into a Scheme?"
Yes. Each case is slightly different so it is always best to let Inandrias staff make such conversions.
They will only do this after they fully understand your criteria and the rationale behind the operation and have a written agreement from you of what is required.
"In which format does Inandrias process periodic Scheme data?"
Inandrias has been programmed to accept input data layouts from the user in pretty much any format.
These are some of the more common formats:
- Spread-sheet
- Delimited text
- Fixed width text
"What should be done if the amount remitted doesn't equal the sum of the debits processed in the input file?"
- Bank the cheque!
- Read the input data into Inandrias and print the edit list.
- Don't post the data at this stage.
- Send the edit list total and a copy of the deposit slip to the client.
- Advise client that you cannot process the data until it balances to the amount received.
"Is it possible to process Renewal updates incorrectly?"
Yes. Not likely, but possible.
Always make a verified backup of the data before executing any lengthy update process like Renewals.
In the event that an update is run out of sequence or run multiple times either revert to the backup (i.e. restore the data) or recover from the Mirror database and Audit Trail (if any).
"Can a Scheme be operated for an Insurance pool?"
Yes, provided that the assets are all in the same class such as motor vehicles or real estate.
"Could Inandrias be used to run a Funeral Scheme?"
Inandrias is ideally suited to running such Schemes. The monthly or periodic member data can be submitted in almost any format including manual!
|
|
|
|
|
|
|
Claims
|
|
"Is it possible to capture Claims retroactively?"
No. Inandrias refuses to load when users change the date on their computers to an earlier date. Users' names are logged on all newly created and modified records so even if a user can cheat the system, the audit trail will spot them doing so!
"Can a claim be registered for a client or a policy not on the system?"
No. Claims are registered against a specific section that had to be "on risk" at the time of the date of loss.
By segregating duties between Underwriters/Brokers and Claims personnel it should be possible to eliminated all potential fraudulent activity. Good management of audit reports should enable managers to quickly spot any collusion.
"Who can change Original Estimates on a claim?"
Own Damage and Third Party original estimates can be changed by users that have been given the authority.
"How does Inandrias identify clients with poor claims record?"
This is achieved using the "Claims ratio" report. This report can be run for the whole database, for specific clients or even for just one client. The report can be previewed and printed where necessary. 1
"Can claims be settled using Inanadrias?"
Yes. Settlements may be made either with cheques or electronic transfer.
"Can settlements be made to third parties?"
Absolutely. Settlements can be made to any party that can receive a cheque or electronic bank transfer. Typically Inandrias is used to pay settlement amounts to:
- Clients
- Third parties
- Assessors
- Legal and medical entities
- Insurers
- Other parties
"How does Inandrias handle many settlements to the same supplier?"
These settlements should be captured in the same batch as far as possible and, providing that the details are correct, all settlement amounts for the same supplier will be totalled onto one cheque or electronic transfer.
"When can settlements be reconciled to the bank account?"
In high value or high volume conditions it is advisable to print a cash journal each day and reconcile it with the days bank statement.
Segregate this duty from that of preparing settlement transactions and that of printing cheques or posting electronic transfers.
"When are claims finalised?"
Typically after all settlements and recoveries have been made and all the outstanding estimates are zero.
"Are claims ever deleted from the system?"
No. Claims captured in error or not followed up can be cancelled rather than finalised, but they do not disappear from the system.
|
|
|
|
|
|
|
|
|
|
"Are the debtors and creditors interlinked in Inandrias?"
Yes. A notable exception is Fee Notes. Fee Notes do not affect any creditors except VAT (in most countries).
"Does Inandrias keep open-item or balance forward accounts?"
All accounts are maintained open-item with various print options to reflect any combination of balance forward and open-item as required. Transactions are optionally archived after three years. These archived records can be stored in a distributed database so that they do not use up valuable space and time in the live data.
"How difficult is it to prepare an Advance remittance bordereaux for each Insurance company?"
From the Insurer's account screen select "Prepare Advance Bordereaux", identify it with something like May2010 and enter the cutoff date as 31/03/2010. Click Process.
Couldn't be easier really!
"Can Agents, Subagents, VAT or other taxes be paid from Inandrias?"
Yes, on a similar basis as paying Insurer's. There is no "Advance Remittance" option for these creditors but all the other detail is exactly the same.
"When selecting records to pay Insurers or other creditors, is it easy to see whether or not the client has paid?"
Yes, even the amount client has paid is shown. The converse is also true. When reviewing Client's account it is possible to see which primary transactions have been paid over to the Insurer.
"What prevents a user from reprinting a debit note for their own use?"
Unfortunately nothing stops an authorised user from reprinting debit or credit notes. The system updates and prints a counter on all reprinted transactions and prints and records the modified date and user name of the change. This call all be reflected in the audit trail.
As with any system, managerial vigilance is key.
"How does the system prevent users from posting receipts on client records where, in fact, no money has changed hands?"
Firstly, segregate the banking to a non-Inandrias user and reconcile the Inandrias daily deposit slips to the bank statement diligently.
Secondly, print the daily receipts register and check each receipt off against the manual receipt book.
"So it's impossible to defraud Inandrias?"
Unfortunately it is not possible to prevent fraud through collusion or other means in any system. Diligence and integrity are still of paramount importance as always.
. |
|
|
|
|
|
|
|
|
|
"Why is the reporting module separate from the main program?"
There are two reasons for this:
- Most Inandrias clients have specific requests and it is easier to maintain these in a separate program file and
- give those Inandrias clients' "super users" the capability to create their own and modify existing reports (having undertaken responsibility for this). Of course, Inandrias staff will help all clients wherever necessary.
"What facilities exist to track down errors if the General Ledger journal does not balance?"
Each time the GL Journal is produced the user is advised how many records were processed out of all the records selected for the period under review.
Every line of the GL journal can be drilled down to see the detail that produced it. When the user finds the transaction(s) that caused the error the GL journal map can be corrected by changing the coding as detailed in the manual and the help system.
"Why is it necessary to print the Trust report by Insurer?"
The Trust report is the tool that can be used to balance against the Trust bank account. The break down by Insurer is designed to help track down any discrepancies and to provide actual income and creditor settlements made to each Insurer.
"Can Inandrias be used to print a balanced General Ledger journal from the debtors and creditors subsidiary ledgers?"
Absolutely The reporting modules contains a powerful GL journal facility. This is set up by Inandrias staff to user requirements and can be modified at any time.
"Who helps out when the Gl journal doesn't balance?"
Actually the system. There is a drill down facility from each GL value to the underlying transactions that produced it. Inandrias staff work with these facilities all the time so they are always available to help where necessary.
|
|
|
|
|
|
|
|
|
|
"Can Inandrias users perform backup of the data from within the program?"
"Can Inandrias users change a user's operability of the system?"
Only if the user making the changes has the correct level of privilege to make such a change.
"How many different sets of data can Inandrias link to?"
There is no practical limit to the number of Inandrias databases that the programs can work with, even simultaneously. Linking to a different dataset is simply a matter of navigating to it and clicking OK. The program can even bring over customised reports like debit notes from the different data sets.
"Can users customise the help texts?"
Yes. Help text is stored by title, abbreviated text, full text and customised text. This means that users can customise the help to their specific requirements even on a daily basis if they wish. The help facility then becomes more of a note pad facility.
"Are diary messages escalated automatically if there has been no action for a specified time period?"
Inandrias can be easily integrated to the diary facility of your choice.
"Is it possible to determine which letters are automatically printed as a result of different actions?"
No. Letters can be changed, added or deleted using the Correspondence tab in the Underwriting module but there is no facility to automate them yet.
|
|
|
|
|
|
|
Other
Audit trail - Mirror database
|
|
|
"What is the main purpose of the Mirror database?"
The Mirror database facility was designed primarily for Audit trail purposes. Every time a difference is detected between the Mirror database and the Current live database the Audit trail is updated and the Mirror is synchronised with the Current.
"Is is possible to have more then one Mirror database?"
Yes. It's possible and may even be beneficial to have several Mirror databases strategically located from close by to far away. This is perfect from a disaster recovery point of view.
In the case of distributed databases it is necessary to run a Mirror for each database in the distribution and these databases MUST be synchronised of course.
"How easy is it to set the time cycle that each Mirror database is updated?"
It's impossible to run a mirror database without setting the cycle time. This could be anything from one minute to one week. Ideally each mirror should have an update cycle time inversely proportional to its distance from the Current live database.
"How many databases can an Inandrias installation be distributed across?"
The current version of Inandrias can link to ten distributed databases. This gives a theoretical database maximum size of twenty gigabytes. In reality the maximum is probably closer to five gigs.
The next version of the system will allow for tables to be split and reunited in the user interface thus giving an unlimited theoretical data size maximum.
"Where can the distributed databases be hosted?"
The current link to data logic expects all the parts of a database to be in the same directory. Theoretically however it is not impossible to have the parts on different machines, even in different countries.
"What is the best way to integrate Inandrias with a website?"
This depends on what you want your website users to be able to see / do. We recommend:
For clients:
- See their policies
- See their accounts
- See their claims
- Obtain quotes
- Register claims
For Insurers / Agents
- See policies registered to them
- See claims against these polices
- See their accounts
- Allow Agents to
- Obtain quotes
- Register new business
- Register claims
"What is the main purpose of the Mirror
database?"
The Mirror database facility was designed primarily for Audit trail
purposes. Every time a difference is detected between the Mirror
database and the Current live database the Audit trail is updated and
the Mirror is synchronised with the Current.
"Is is
possible to have more then one Mirror database?"
Yes. It's possible and may even be beneficial to have several
Mirror databases strategically located from close by to far away. This
is perfect from a disaster recovery point of view.
In the case of distributed databases it is necessary to run a
Mirror for each database in the distribution and these databases MUST be
synchronised of course.
"How
easy is it to set the time cycle that each Mirror database is updated?"
It's impossible to run a mirror database without setting the cycle
time. This could be anything from one minute to one week. Ideally
each mirror should have an update cycle time inversely proportional to
its distance from the Current live database.
"How many
databases can an Inandrias installation be distributed across?"
The current version of Inandrias can link to ten distributed
databases. This gives a theoretical database maximum size of twenty
gigabytes. In reality the maximum is probably closer to five gigs.
The next version of the system will allow for tables to be split
and reunited in the user interface thus giving an unlimited theoretical
data size maximum.
"Where
can the distributed databases be hosted?"
The current link to data logic expects all the parts of a database
to be in the same directory. Theoretically however it is not impossible
to have the parts on different machines, even in different countries.
"What is the
best way to integrate Inandrias with a website?"
This depends on what you want your website users to be able to see /
do. We recommend:
For clients:
- See their policies
- See their accounts
- See their claims
- Obtain quotes
- Register claims
For Insurers / Agents
- See policies registered to them
- See claims against these polices
- See their accounts
- Allow Agents to
- Obtain quotes
- Register new business
- Register claims
"What is the main purpose of the Mirror
database?"
The Mirror database facility was designed primarily for Audit trail
purposes. Every time a difference is detected between the Mirror
database and the Current live database the Audit trail is updated and
the Mirror is synchronised with the Current.
"Is is
possible to have more then one Mirror database?"
Yes. It's possible and may even be beneficial to have several
Mirror databases strategically located from close by to far away. This
is perfect from a disaster recovery point of view.
In the case of distributed databases it is necessary to run a
Mirror for each database in the distribution and these databases MUST be
synchronised of course.
"How
easy is it to set the time cycle that each Mirror database is updated?"
It's impossible to run a mirror database without setting the cycle
time. This could be anything from one minute to one week. Ideally
each mirror should have an update cycle time inversely proportional to
its distance from the Current live database.
"How many
databases can an Inandrias installation be distributed across?"
The current version of Inandrias can link to ten distributed
databases. This gives a theoretical database maximum size of twenty
gigabytes. In reality the maximum is probably closer to five gigs.
The next version of the system will allow for tables to be split
and reunited in the user interface thus giving an unlimited theoretical
data size maximum.
"Where
can the distributed databases be hosted?"
The current link to data logic expects all the parts of a database
to be in the same directory. Theoretically however it is not impossible
to have the parts on different machines, even in different countries.
"What is the
best way to integrate Inandrias with a website?"
This depends on what you want your website users to be able to see /
do. We recommend:
For clients:
- See their policies
- See their accounts
- See their claims
- Obtain quotes
- Register claims
For Insurers / Agents
- See policies registered to them
- See claims against these polices
- See their accounts
- Allow Agents to
- Obtain quotes
- Register new business
- Register claims
|
|
|
|
|
|
|
|
|
|
"Why does Inandrias use MS Access and not a more 'industry strength' database like Oracle or Microsoft's Sequel Server on the back end?"
If you have an effective and knowledgeable IT team then we will make Inandrias work with the database of your choice as the data repository. But if you prefer to keep costs down and flexibility high then read our Why Access? FAQ page.
The more expensive 'industry strength' databases require expensive data base administrators to take care of them. Don't let the experts lure you into an unnecessary trap. If all your business units and / or branch locations are smaller than twenty users then Inandrias is a most resilient solution and inexpensive answer to prayer!
|
|
|
|
|
|
|
1. For the well being of our planet please avoid using paper. | | |
|
|
|
|
|
|
|
|
|
