We do have working CI, so the actual challenge is to put the (partially confidential) prod config in a place where the/any CI system can access it.
Does "Until we have a souped-up Jenkins solution" imply that there already was a decision against using this particular piece of software? What was the rationale?

In my understanding, at the moment we have the policy of "configuration is only stored on servers located in Germany, more or less under our control and accessed only with SSH via our user accounts (for changing) or the dedicated deploy account (for actual deployment)". That means our current CI for the fundraising frontend (Travis CI) can't and should not have access to the config. An alternative to the proposed solution would be to discuss if our current policy still makes sense and how to give Travis CI access to it (access a way that is of roughly equal complexity as this cron job).

The phrase "Until we have a souped-up Jenkins solution" should convey the long-term plans to move from Travis CI to Jenkins for the Fundraising Frontend. It's my impression this won't happen in 2017, while this easy quick-fix would be feasible to do in a sprint and would protect us from ourselves.

Taking your 1st paragraph as a hard requirement (which I deem reasonable) are there any arguments against a smooth transition from travis to jenkins, with config validation as the first isolated task done on jenkins? There surely is a major arguments against this: cost of ownership (maintaining two build systems, redundant builds), but we would not have to add extra infrastructure, just throw more use at it, and the proposed "cron job" is not without cost either and has my alarm bells ringing...