We’re still very old school from an actuarial-specific data perspective. We’ve got stuff stored in Access, SAS datasets, various spreadsheets, that we all acknowledge is a bad way of doing things. We’ve had discussions around just giving us (the actuarial team) ‘write’ access, whereas we typically only have ‘read’ access. However, even then, we would have to request a specific database structure that would be created by DBAs, and we would only be able to fill existing tables, as opposed to making stuff as we go. That seems like a nuisance, but I get it from a security and production efficiency perspective. Does anyone here, at an insurance entity, actually have free reign over your own database(s)?
I would describe what we use is essentially “two environments” for our data sources:
-
“Raw source” database that is managed by DBA’s outside of our area (like IT). We will use this a the “main” source of information about the company’s book of business.
-
“Internal” database that is managed by DBA’s associated with our area. We will perform ETL’s from the “Raw source” and store out results here. This is usually the place we will pull data for other tools (like reports or dashboards). (Note that one-off’s are likely to pull from the “Raw source”.)
If your area doesn’t have a DBA type (we call them data engineers), it might be worth the expense to get that internal db set up. They can also learn your area’s needs–and reasons for those needs–and they can act as your liaison to the IT’s DBA’s since they’ll be better versed with the lingo and processes to make communications more efficient (and effective!).
That’s helpful, thanks! I stole an IT employee a couple years ago to work on getting data sorted out to streamline predictive modeling dataset creation, which has expanded to effectively trying to create your internal piece, what we’re calling a future actuarial data mart. Our production data isn’t so bad, but pulling in archived historical data is a mess. Everything gets chopped into pieces to make storage more efficient (designed based on a system from the late 80s). I anticipate several iterations of trying to get it figured out, so the limitations on our direct creation are frustrating.
This sounds similar to my world.
I have a single repository of gospel data. Changes to that repository are strictly and formally controlled, although actuaries have effectively free reign to read that data. I control one field of one table of that central repository (a simple mapping to facilitate my team’s work); when I need to update how that field is populated, there’s a formal change process I have to follow.
For “my work”, I have my own sandbox within which I have full write access. It would be impractical if I had to go to IT every time I needed to make a structural change. However, because some of my work impacts externally published financials, there are rigorous and somewhat annoying controls and documentation requirements in place to ensure that I don’t run amok, and to facilitate continuity should something happen to me.
There is still the risk that something could happen and my sandbox would be corrupted/ruined…but we do have relatively strict access controls on our sandboxes, and we do have backups.
1 Like
Yeah, having that sandbox is a good way to get things figured out and then you can either “push to production” the final version/process or show the IT folks what you want and how it should look.
The problem is often being able to get “production data” accessible from that sandbox.
“Sandbox” is perhaps not the best term for that bit of cloud I’m playing in, as it ends up being both test and production. An argument could be made that I should have two spaces, one for “normal experimentation” and one for “production”.
Also, for context, these days I work in the insurance risk element of capital modeling, and my prior life was in supporting (pricing and product development) new or small business units. My needs may be more dynamic than other actuaries…which is why, for IT purposes, it’s most practical to just give me a place where I can engage in my arcana, and rely on oversight to ensure I don’t go too far off the rails within that space.
1 Like
I get the hybrid vibe. I want to tinker with the way I calculate IBNR, most desirably by pulling loss information out of ‘gospel’ and into ‘sandbox’, and doing some new stuff. But I want an eventual ‘gospel’ repository of that IBNR to be accessible by Accounting outside of a spreadsheet.
…and you’re now getting into the problem of simplifying the description to “gospel” vs “sandbox”. 
In my world, a final-final view of IBNR (with details for nominal point estimate, risk adjustment, and discount) are fed to and maintained/archived in the gospel source.
The work to come up with those final-final values are maintained in the sandboxes. While an argument can be made that we should have a more-locked-down, formally-managed environment for the final iteration of that work. It’s important for documentation and review purposes; there is the potential for useful knock-on uses; etc. However, “we” manage that. If we add too much bureaucracy…we’d be too inefficient, or require too much resource, to get our work done.
1 Like
I think I have complete control over our databases. More than I need or want or should have, but it’s nice I can give users permissions when stupid things like access to a user function is blocked.
I’ve never broken anything, so it’s never been discussed all that much.
1 Like
Thanks for all the replies! Back from a lengthy conference trip to the PNW that was lovely! But led to you all being ignored.
Our final-final IBNR is I guess technically stored in the Gospel of Accounting, aka a general ledger entry somewhere. But the workflow of I have spreadsheets that feed their spreadsheets that feed other spreadsheets that are entered into the ledger feels like too much. Also I can’t access the ledger entries which I’m only recently beginning to find frustrating.